坑爹的Python陷阱(避坑指南)
我個人對陷阱的定義是這樣的:程式碼看起來可以工作,但不是以你“想當然“”的方式。如果一段程式碼直接出錯,丟擲了異常,我不認為這是陷阱。比如,Python程式設計師應該都遇到過的“UnboundLocalError”, 示例:
>>> a=1
>>> def func():
... a+=1
... print a
...
>>> func()
traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in func
UnboundLocalError: local variable a referenced before assignment
對於“UnboundLocalError”,還有更高階的版本:
import random
def func(ok):
if ok:
a = random.random()
else:
import random
a = random.randint(1, 10)
return a
func(True)# UnboundLocalError: local variable random referenced before assignment
可能對於很多python新手來說,這個Error讓人摸不著頭腦。但我認為這不算陷阱,因為這段程式碼一定會報錯,而不是默默的以錯誤的方式執行。不怕真小人,就怕偽君子。我認為缺陷就好比偽君子。
那麼Python中哪些真正算得上陷阱呢
第一:以mutable物件作為預設引數
這個估計是最廣為人知的了,Python和其他很多語言一樣,提供了預設引數,預設引數確實是個好東西,可以讓函式呼叫者忽略一些細節(比如GUI程式設計,Tkinter,QT),對於lambda表示式也非常有用。但是如果使用了可變物件作為預設引數,那麼事情就不那麼愉快了
>>> def f(lst = []):
... lst.append(1)
... return lst
...
>>> f()
[1]
>>> f()
[1, 1]
驚喜不驚喜?!究其原因,python中一切都是物件,函式也不列外,預設引數只是函式的一個屬性。而預設引數在函式定義的時候已經求值了。
Default parameter values are evaluated when the function definition is executed.
stackoverflow上有一個更適當的例子來說明預設引數是在定義的時候求值,而不是呼叫的時候。
>>> import time
>>> def report(when=time.time()):
... return when
...
>>> report()
1500113234.487932
>>> report()
1500113234.487932
python docoment 給出了標準的解決辦法:
A way around this is to use None as the default, and explicitly test for it in the body of the function
>>> def report(when=None):
... if when is None:
... when = time.time()
... return when
...
>>> report()
1500113446.746997
>>> report()
1500113448.552873
第二: x += y vs x = x + y
一般來說,二者是等價的,至少看起來是等價的(這也是陷阱的定義 — 看起來都OK,但不一定正確)。
>>> x=1;x += 1;print x
2
>>> x=1;x = x+1;print x
2
>>> x=[1];x+=[2];print x
[1, 2]
>>> x=[1];x=x+[2];print x
[1, 2]
呃,被光速打臉了?
>>> x=[1];print id(x);x=x+[2];print id(x)
4357132800
4357132728
>>> x=[1];print id(x);x+=[2];print id(x)
4357132800
4357132800
前者x指向一個新的物件,後者x在原來的物件是修改,當然,那種效果是正確的取決於應用場景。至少,得知道,二者有時候並不一樣
第三,神奇的小括號—()
小括號(parenthese)在各種程式語言中都有廣泛的應用,python中,小括號還能表示元組(tuple)這一資料型別, 元組是immutable的序列。
>>> a = (1, 2)
>>> type(a)
<type tuple >
>>> type(())
<type tuple >
但如果只有一個元素呢
>>> a=(1)
>>> type(a)
<type int >
神奇不神奇,如果要表示只有一個元素的元組,正確的姿勢是:
>>> a=(1,)
>>> type(a)
<type tuple >
第四:生成一個元素是列表的列表
這個有點像二維陣列,當然生成一個元素是字典的列表也是可以的,更通俗的說,生成一個元素是可變物件的序列
很簡單嘛:
>>> a= [[]] * 10
>>> a
[[], [], [], [], [], [], [], [], [], []]
>>> a[0].append(10)
>>> a[0]
[10]
看起來很不錯,簡單明瞭,but
>>> a[1]
[10]
>>> a
[[10], [10], [10], [10], [10], [10], [10], [10], [10], [10]]
我猜,這應該不是你預期的結果吧,究其原因,還是因為python中list是可變物件,上述的寫法大家都指向的同一個可變物件,正確的姿勢
>>> a = [[] for _ in xrange(10)]
>>> a[0].append(10)
>>> a
[[10], [], [], [], [], [], [], [], [], []]
另外一個在實際編碼中遇到的問題,dict.fromkeys, 也有異曲同工之妙:建立的dict的所有values指向同一個物件。
fromkeys(seq[, value])
Create a new dictionary with keys from seq and values set to value.
第五,在訪問列表的時候,修改列表
列表(list)在python中使用非常廣泛,當然經常會在訪問列表的時候增加或者刪除一些元素。比如,下面這個函式,試圖刪掉列表中為3的倍數的元素:
>>> def modify_lst(lst):
... for idx, elem in enumerate(lst):
... if elem % 3 == 0:
... del lst[idx]
...
測試一下,
>>> lst = [1,2,3,4,5,6]
>>> modify_lst(lst)
>>> lst
[1, 2, 4, 5]
好像沒什麼錯,不過這只是運氣好
>>> lst = [1,2,3,6,5,4]
>>> modify_lst(lst)
>>> lst
[1, 2, 6, 5, 4]
上面的例子中,6這個元素就沒有被刪除。如果在modify_lst函式中print idx, item就可以發現端倪:lst在變短,但idx是遞增的,所以在上面出錯的例子中,當3被刪除之後,6變成了lst的第2個元素(從0開始)。在C++中,如果遍歷容器的時候用迭代器刪除元素,也會有同樣的問題。
如果邏輯比較簡單,使用list comprehension是不錯的注意
第六,閉包與lambda
這個也是老生長談的例子,在其他語言也有類似的情況。先看一個例子:
>>> def create_multipliers():
... return [lambda x:i*x for i in range(5)]
...
>>> for multiplier in create_multipliers():
... print multiplier(2)
...
create_multipliers函式的返回值時一個列表,列表的每一個元素都是一個函式 -- 將輸入引數x乘以一個倍數i的函式。預期的結果時0,2,4,6,8. 但結果是5個8,意外不意外。
由於出現這個陷阱的時候經常使用了lambda,所以可能會認為是lambda的問題,但lambda表示不願意背這個鍋。問題的本質在與python中的屬性查詢規則,LEGB(local,enclousing,global,bulitin),在上面的例子中,i就是在閉包作用域(enclousing),而Python的閉包是 遲繫結 , 這意味著閉包中用到的變數的值,是在內部函式被呼叫時查詢得到的。
解決辦法也很簡單,那就是變閉包作用域為區域性作用域。
>>> def create_multipliers():
... return [lambda x, i = i:i*x for i in range(5)]
...
第七,定義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程式碼如下:
l = []
class A(object):
pass
main.py程式碼如下:
def add(x):
from mypackage import mymodule
mymodule.l.append(x)
print "updated list",mymodule.l, id(mymodule)
def get():
import mymodule
print module in get , id(mymodule)
return mymodule.l
if __name__ == __main__ :
import sys
sys.path.append( ../ )
add(1)
ret = get()
print "lets check", ret
執行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中的一些缺陷,這是一份不完全列表,歡迎大家補充。
references:
instagram-pycon-2017
python-2-x-gotchas-and-landmines
module-reimported-if-imported-from-different-path
本文版權歸作者xybaby
原文地址:http://www.cnblogs.com/xybaby/)
喜歡文章,點個在看
相關文章
- 十二個坑爹的Python陷阱Python
- Redis開發運維的陷阱及避坑指南Redis運維
- .NET AsyncLocal 避坑指南
- 上雲避坑指南
- React Hooks使用避坑指南ReactHook
- Redis 安裝避坑指南Redis
- eBPF編寫避坑指南eBPF
- 避坑手冊 | JAVA編碼中容易踩坑的十大陷阱Java
- MySQL 之 LEFT JOIN 避坑指南MySql
- Shell 指令碼避坑指南(一)指令碼
- 微信支付開發避坑指南
- 坑爹的Sun JDKJDK
- JavaScript作用域面試題避坑指南JavaScript面試題
- Flutter beta3 避坑指南1Flutter
- 坑爹的驗證碼。。
- 坑爹的Oracle 11.2.0.3Oracle
- 坑爹的IE8
- Linux下Python3.6的安裝及避坑指南LinuxPython
- 遊戲人避坑指南——怎樣才能減少踩坑的頻率?遊戲
- 從單體邁向 Serverless 的避坑指南Server
- TensorFlow-GPU安裝避坑指南GPU
- 海外電商支付閘道器避坑指南
- Docker安裝flink及避坑指南Docker
- Mac 安裝 Hadoop 教程【避坑指南】MacHadoop
- 程式設計師避坑指南36條程式設計師
- 個人資訊保安避坑指南“宅家篇”
- H2 資料庫避坑指南資料庫
- 避坑手冊!Python 對比兩個 datetime 大小的坑Python
- Canal v1.1.4版本避坑指南
- 微服務進階之路 容器落地避坑指南微服務
- MongoDB 最佳實踐和場景避坑指南MongoDB
- Windows 11 預覽版安裝避坑指南Windows
- 外出遊玩最全個人資訊保安避坑“指南”
- 微服務轉型的三大誤區,避坑指南→微服務
- 避坑指南之財務共享中心的服務管理
- 避坑指南:關於SPDK問題分析過程
- Redis避坑指南:為什麼要有分散式鎖?Redis分散式
- 踩坑CBO,解決那些坑爹的SQL優化問題SQL優化