十二個坑爹的Python陷阱

我我的對陷阱的定義是這樣的：代碼看起來能夠工做，但不是以你「想固然「」的方式。若是一段代碼直接出錯，拋出了異常，我不認爲這是陷阱。好比，Python程序員應該都遇到過的「UnboundLocalError」, 示例：

對於「UnboundLocalError」,還有更高級的版本：

可能對於不少python新手來講，這個Error讓人摸不着頭腦。但我認爲這不算陷阱，由於這段代碼必定會報錯，而不是默默的以錯誤的方式運行。不怕真小人，就怕僞君子。我認爲缺陷就比如僞君子。

那麼Python中哪些真正算得上陷阱呢

第一：以mutable對象做爲默認參數

這個估計是最廣爲人知的了，Python和其餘不少語言同樣，提供了默認參數，默認參數確實是個好東西，可讓函數調用者忽略一些細節（好比GUI編程，Tkinter，QT），對於lambda表達式也很是有用。可是若是使用了可變對象做爲默認參數，那麼事情就不那麼愉快了

驚喜不驚喜？！究其緣由，python中一切都是對象，函數也不列外，默認參數只是函數的一個屬性。而默認參數在函數定義的時候已經求值了。

Default parameter values are evaluated when the function definition is executed.

stackoverflow上有一個更適當的例子來講明默認參數是在定義的時候求值，而不是調用的時候。

python docoment 給出了標準的解決辦法：

A way around this is to use None as the default, and explicitly test for it in the body of the function

第二: x += y vs x = x + y

通常來講，兩者是等價的，至少看起來是等價的（這也是陷阱的定義 — 看起來都OK，但不必定正確）。

呃，被光速打臉了？

前者x指向一個新的對象，後者x在原來的對象是修改，固然，那種效果是正確的取決於應用場景。至少，得知道，兩者有時候並不同

第三，神奇的小括號—()

小括號（parenthese）在各類編程語言中都有普遍的應用，python中，小括號還能表示元組（tuple）這一數據類型, 元組是immutable的序列。

但若是隻有一個元素呢

神奇不神奇，若是要表示只有一個元素的元組，正確的姿式是:

第四：生成一個元素是列表的列表

這個有點像二維數組，固然生成一個元素是字典的列表也是能夠的，更通俗的說，生成一個元素是可變對象的序列

很簡單嘛：

看起來很不錯，簡單明瞭，but

我猜，這應該不是你預期的結果吧，究其緣由，仍是由於python中list是可變對象，上述的寫法你們都指向的同一個可變對象，正確的姿式

另一個在實際編碼中遇到的問題，dict.fromkeys, 也有殊途同歸之妙： 建立的dict的全部values指向同一個對象。

fromkeys(seq[, value])
複製代碼

Create a new dictionary with keys from seq and values set to value.

第五，在訪問列表的時候，修改列表

列表（list）在python中使用很是普遍，固然常常會在訪問列表的時候增長或者刪除一些元素。好比，下面這個函數，試圖刪掉列表中爲3的倍數的元素：

測試一下，

好像沒什麼錯，不過這只是運氣好

上面的例子中，6這個元素就沒有被刪除。若是在modify_lst函數中print idx， item就能夠發現端倪：lst在變短，但idx是遞增的，因此在上面出錯的例子中，當3被刪除以後，6變成了lst的第2個元素（從0開始）。在C++中，若是遍歷容器的時候用迭代器刪除元素，也會有一樣的問題。

若是邏輯比較簡單，使用list comprehension是不錯的注意

第六，閉包與lambda

這個也是老生長談的例子，在其餘語言也有相似的狀況。先看一個例子:

create_multipliers函數的返回值時一個列表，列表的每個元素都是一個函數 －－ 將輸入參數x乘以一個倍數i的函數。預期的結果時0，2，4，6，8. 但結果是5個8，意外不意外。

因爲出現這個陷阱的時候常用了lambda，因此可能會認爲是lambda的問題，但lambda表示不肯意背這個鍋。問題的本質在與python中的屬性查找規則，LEGB（local，enclousing，global，bulitin），在上面的例子中，i就是在閉包做用域（enclousing），而Python的閉包是 遲綁定 ， 這意味着閉包中用到的變量的值，是在內部函數被調用時查詢獲得的。

解決辦法也很簡單，那就是變閉包做用域爲局部做用域。

第七，定義del

大多數計算機專業的同窗可能都是先學的C、C++，構造、析構函數的概念應該都很是熟。因而，當切換到python的時候，天然也想知道有沒有相應的函數。好比，在C++中很是有名的RAII，即經過構造、析構來管理資源（如內存、文件描述符）的聲明週期。那在python中要達到一樣的效果怎麼作呢，即須要找到一個對象在銷燬的時候必定會調用的函數，因而發現了init, del函數，可能簡單寫了兩個例子發現確實也能工做。但事實上可能掉進了一個陷阱，在python documnet是有描述的：

Circular references which are garbage are detected when the option cycle detector is enabled (it’s on by default), but can only be cleaned up if there are no Python-level del() methods involved.

簡單來講，若是在循環引用中的對象定義了del,那麼python gc不能進行回收，所以，存在內存泄漏的風險

第八，不一樣的姿式import同一個module

示例在stackoverflow的例子上稍做修改，假設如今有一個package叫mypackage，裏面包含三個python文件：mymodule.py, main.py, init.py。mymodule.py代碼以下：

main.py代碼以下：

運行python main.py，結果以下：

updated list [1] 4406700752
module in get 4406700920
lets check []
複製代碼

從運行結果能夠看到，在add 和 get函數中import的mymodule不是同一個module，ID不一樣。固然，在python2.7.10中，須要main.py的第13行才能出現這樣的效果。你可能會問，誰會寫出第13行這樣的代碼呢？事實上，在不少項目中，爲了import的時候方便，會往sys.path加入一堆路徑。那麼在項目中，你們贊成一種import方式就很是有必要了

第九，python升級

python3.x並不向後兼容，因此若是從2.x升級到3.x的時候得當心了，下面列舉兩點：

在python2.7中，range的返回值是一個列表；而在python3.x中，返回的是一個range對象。

map()、filter()、 dict.items()在python2.7返回列表，而在3.x中返回迭代器。固然迭代器大多數都是比較好的選擇，更加pythonic，可是也有缺點，就是隻能遍歷一次。在instagram的分享中，也提到由於這個致使的一個坑爹的bug。

第十：++i —i

這個陷阱主要是坑來自C、C++背景的同窗。簡單來講，++i是對i取兩次正號，—i是對i取兩次負號，運算完以後i的值不變。

第十一： setattr getattr getattribute

Python中有大量的magic method（形似xx），其中許多跟屬性訪問有關，好比get， set，delete_，getattr, setattr, delattr, getattribute。前三個跟descriptor相關，詳細可參見《python descriptor 詳解》。坑爹的是，getattr與setattr相差很大，在《python屬性查找（attribute look up）》一文中有詳細介紹。簡單說來，setattr與getattribute是對應的，都是修改python默認的屬性修改、查找機制，而getattr只是默認查找機制沒法找到屬性的時候纔會調用，setattr應該叫setattribute__才恰當！

第負一，gil

以GIL結尾，由於gil是Python中你們公認的缺陷！

其餘語言過來的同窗可能看到python用threading模塊，拿過來就用，結果發現效果不對啊，而後就會噴，什麼鬼

總結：

毫無疑問的說，python是很是容易上手，也很是強大的一門語言。python很是靈活，可定製化很強。同時，也存在一些陷阱，搞清楚這些陷阱可以更好的掌握、使用這麼語言。本文列舉了一些python中的一些缺陷，這是一份不徹底列表，歡迎你們補充。