關于Python
Python是一種解釋性、面向?qū)ο蟛⒕哂袆討B(tài)語 義的高級程序語言。它內(nèi)建了高級的數(shù)據(jù)結構，結合了動態(tài)類型和動態(tài)綁定的優(yōu)點，這使得它在快速應用開發(fā)中非常有吸引力，并且可作為腳本或膠水語言來連接現(xiàn)有的組件或服務。Python支持模塊和包，從而鼓勵了程序的模塊化和代碼重用。
關于這篇文章
Python簡單易學的語法可能會使Python開發(fā)者–尤其是那些編程的初學者–忽視了它的一些微妙的地方并低估了這門語言的能力。
有鑒于此，本文列出了一個“10強”名單，枚舉了甚至是高級Python開發(fā)人員有時也難以捕捉的錯誤。
|
頂 翻譯的不錯哦!
|
|
其它翻譯版本(1)
|
常見錯誤 #1: 濫用表達式作為函數(shù)參數(shù)的默認值
Python允許為函數(shù)的參數(shù)提供默認的可選值。盡管這是語言的一大特色，但是它可能會導致一些易變默認值的混亂。例如，看一下這個Python函數(shù)的定義：
1 | >>> def foo(bar=[]): # bar is optional and defaults to [] if not specified |
2 | ... bar.append("baz") # but this line could be problematic, as we'll see... |
一個常見的錯誤是認為在函數(shù)每次不提供可選參數(shù)調(diào)用時可選參數(shù)將設置為默認指定值。在上面的代碼中，例如，人們可能會希望反復（即不明確指定bar參數(shù)）地調(diào)用foo()時總返回'baz'，由于每次foo()調(diào)用時都假定（不設定bar參數(shù)）bar被設置為[]（即一個空列表）。 |
頂 翻譯的不錯哦!
|
但是讓我們看一下這樣做時究竟會發(fā)生什么：
耶？為什么每次foo()調(diào)用時都要把默認值"baz"追加到現(xiàn)有列表中而不是創(chuàng)建一個新的列表呢？
答案是函數(shù)參數(shù)的默認值只會評估使用一次—在函數(shù)定義的時候。因此，bar參數(shù)在初始化時為其默認值（即一個空列表），即foo()首次定義的時候，但當調(diào)用foo()時（即，不指定bar參數(shù)時）將繼續(xù)使用bar原本已經(jīng)初始化的參數(shù)。
下面是一個常見的解決方法：
02 | ... if bar is None: # or if not bar: |
|
頂 翻譯的不錯哦!
|
常見錯誤 #2: 錯誤地使用類變量
考慮一下下面的例子：
10 | >>> print A.x, B.x, C.x |
常規(guī)用一下。
嗯，再試一下也一樣。
什么 $%#!&?? 我們只改了A.x，為什么C.x也改了?
在Python中，類變量在內(nèi)部當做字典來處理，其遵循常被引用的方法解析順序（MRO）。所以在上面的代碼中，由于class C中的x屬性沒有找到，它會向上找它的基類（盡管Python支持多重繼承，但上面的例子中只有A）。換句話說，class C中沒有它自己的x屬性，其獨立于A。因此，C.x事實上是A.x的引用。 |
頂 翻譯的不錯哦!
|
常見錯誤 #3: 為 except 指定錯誤的參數(shù)
假設你有如下一段代碼：
4 | ... except ValueError, IndexError: # To catch both exceptions, right? |
7 | Traceback (most recent call last): |
8 | File "<stdin>", line 3, in <module> |
9 | IndexError: list index out of range |
這里的問題在于 except 語句并不接受以這種方式指定的異常列表。相反，在Python 2.x中，使用語法 except Exception, e 是將一個異常對象綁定到第二個可選參數(shù)（在這個例子中是 e）上，以便在后面使用。所以，在上面這個例子中，IndexError 這個異常并不是被except語句捕捉到的，而是被綁定到一個名叫 IndexError的參數(shù)上時引發(fā)的。
在一個except語句中捕獲多個異常的正確做法是將第一個參數(shù)指定為一個含有所有要捕獲異常的元組。并且，為了代碼的可移植性，要使用as關鍵詞，因為Python 2 和Python 3都支持這種語法：
4 | ... except (ValueError, IndexError) as e: |
|
頂 翻譯的不錯哦!
|
常見錯誤 #4: 不理解Python的作用域
Python是基于 LEGB 來進行作用于解析的, LEGB 是 Local, Enclosing, Global, Built-in 的縮寫?？雌饋怼耙娢闹狻保瑢?？實際上，在Python中還有一些需要注意的地方，先看下面一段代碼：
07 | Traceback (most recent call last): |
08 | File "<stdin>", line 1, in <module> |
09 | File "<stdin>", line 2, in foo |
10 | UnboundLocalError: local variable 'x' referenced before assignment |
這里出什么問題了？
上面的問題之所以會發(fā)生是因為當你給作用域中的一個變量賦值時，Python 會自動的把它當做是當前作用域的局部變量，從而會隱藏外部作用域中的同名變量。
很多人會感到很吃驚，當他們給之前可以正常運行的代碼的函數(shù)體的某個地方添加了一句賦值語句之后就得到了一個 UnboundLocalError 的錯誤。 (你可以在這里了解到更多) |
頂 翻譯的不錯哦!
|
尤其是當開發(fā)者使用 lists 時，這個問題就更加常見. 請看下面這個例子：
03 | ... lst.append(5) # 沒有問題... |
11 | ... lst += [5] # ... 但是這里有問題! |
14 | Traceback (most recent call last): |
15 | File "<stdin>", line 1, in <module> |
16 | File "<stdin>", line 2, in foo |
17 | UnboundLocalError: local variable 'lst' referenced before assignment |
嗯？為什么 foo2 報錯，而foo1沒有問題呢？
原因和之前那個例子的一樣，不過更加令人難以捉摸。foo1 沒有對 lst 進行賦值操作，而 foo2 做了。要知道， lst += [5] 是 lst = lst + [5] 的縮寫，我們試圖對 lst 進行賦值操作（Python把他當成了局部變量）。此外，我們對 lst 進行的賦值操作是基于 lst 自身（這再一次被Python當成了局部變量），但此時還未定義。因此出錯！ |
頂 翻譯的不錯哦!
|
常見錯誤#5：當?shù)鷷r修改一個列表（List）
下面代碼中的問題應該是相當明顯的：
1 | >>> odd = lambda x : bool(x % 2) |
2 | >>> numbers = [n for n in range(10)] |
3 | >>> for i in range(len(numbers)): |
5 | ... del numbers[i] # BAD: Deleting item from a list while iterating over it |
7 | Traceback (most recent call last): |
8 | File "<stdin>", line 2, in <module> |
9 | IndexError: list index out of range |
當?shù)臅r候，從一個 列表 （List）或者數(shù)組中刪除元素，對于任何有經(jīng)驗的開發(fā)者來說，這是一個眾所周知的錯誤。盡管上面的例子非常明顯，但是許多高級開發(fā)者在更復雜的代碼中也并非是故意而為之的。
幸運的是，Python包含大量簡潔優(yōu)雅的編程范例，若使用得當，能大大簡化和精煉代碼。這樣的好處是能得到更簡化和更精簡的代碼，能更好的避免程序中出現(xiàn)當?shù)鷷r修改一個列表（List）這樣的bug。一個這樣的范例是遞推式列表（list comprehensions）。而且，遞推式列表（list comprehensions）針對這個問題是特別有用的，通過更改上文中的實現(xiàn)，得到一段極佳的代碼：
1 | >>> odd = lambda x : bool(x % 2) |
2 | >>> numbers = [n for n in range(10)] |
3 | >>> numbers[:] = [n for n in numbers if not odd(n)] # ahh, the beauty of it all |
|
頂 翻譯的不錯哦!
|
常見錯誤 #6: 不明白Python在閉包中是如何綁定變量的
看下面這個例子：
1 | >>> def create_multipliers(): |
2 | ... return [lambda x : i * x for i in range(5)] |
3 | >>> for multiplier in create_multipliers(): |
你也許希望獲得下面的輸出結果：
但實際的結果卻是：
驚訝吧!
這之所以會發(fā)生是由于Python中的“后期綁定”行為——閉包中用到的變量只有在函數(shù)被調(diào)用的時候才會被賦值。所以，在上面的代碼中，任何時候，當返回的函數(shù)被調(diào)用時，Python會在該函數(shù)被調(diào)用時的作用域中查找 i 對應的值（這時，循環(huán)已經(jīng)結束，所以 i 被賦上了最終的值——4）。
解決的方法有一點hack的味道：
01 | >>> def create_multipliers(): |
02 | ... return [lambda x, i=i : i * x for i in range(5)] |
04 | >>> for multiplier in create_multipliers(): |
05 | ... print multiplier(2) |
在這里，我們利用了默認參數(shù)來生成一個匿名的函數(shù)以便實現(xiàn)我們想要的結果。有人說這個方法很巧妙，有人說它難以理解，還有人討厭這種做法。但是，如果你是一個 Python 開發(fā)者，理解這種行為很重要。 |
頂 翻譯的不錯哦!
|
常見錯誤 #7: 創(chuàng)建循環(huán)依賴模塊
讓我們假設你有兩個文件，a.py 和 b.py，他們之間相互引用，如下所示：
a.py:
b.py:
首先，讓我們嘗試引入 a.py：
可以正常工作。這也許是你感到很奇怪。畢竟，我們確實在這里引入了一個循環(huán)依賴的模塊，我們推測這樣會出問題的，不是嗎？
答案就是在Python中，僅僅引入一個循環(huán)依賴的模塊是沒有問題的。如果一個模塊已經(jīng)被引入了，Python并不會去再次引入它。但是，根據(jù)每個模塊要訪問其他模塊中的函數(shù)和變量位置的不同，就很可能會遇到問題。 |
頂 翻譯的不錯哦!
|
所以，回到我們這個例子，當我們引入 a.py 時，再引入 b.py 不會產(chǎn)生任何問題，因為當引入的時候，b.py 不需要 a.py 中定義任何東西。b.py 中唯一引用 a.py 中的東西是調(diào)用 a.f()。 但是那個調(diào)用是發(fā)生在g() 中的，并且 a.py 和 b.py 中都沒有調(diào)用 g()。所以運行正常。
但是，如果我們嘗試去引入b.py 會發(fā)生什么呢？（在這之前不引入a.py），如下所示:
02 | Traceback (most recent call last): |
03 | File "<stdin>", line 1, in <module> |
04 | File "b.py", line 1, in <module> |
06 | File "a.py", line 6, in <module> |
08 | File "a.py", line 4, in f |
10 | AttributeError: 'module' object has no attribute 'x' |
啊哦。 出問題了！此處的問題是，在引入b.py的過程中，Python嘗試去引入 a.py，但是a.py 要調(diào)用f()，而f() 有嘗試去訪問 b.x。但是此時 b.x 還沒有被定義呢。所以發(fā)生了 AttributeError 異常。
至少，解決這個問題很簡單，只需修改b.py，使其在g()中引入 a.py：
4 | import a # 只有當g()被調(diào)用的時候才會引入a |
現(xiàn)在，當我們再引入b，沒有任何問題：
3 | 1 # Printed a first time since module 'a' calls 'print f()' at the end |
4 | 1 # Printed a second time, this one is our call to 'g' |
|
頂 翻譯的不錯哦!
|
常見錯誤 #8: 與Python標準庫中的模塊命名沖突
Python一個令人稱贊的地方是它有豐富的模塊可供我們“開箱即用”。但是，如果你沒有有意識的注意的話，就很容易出現(xiàn)你寫的模塊和Python自帶的標準庫的模塊之間發(fā)生命名沖突的問題（如，你也許有一個叫 email.py 的模塊，但這會和標準庫中的同名模塊沖突）。
這可能會導致很怪的問題，例如，你引入了另一個模塊，但這個模塊要引入一個Python標準庫中的模塊，由于你定義了一個同名的模塊，就會使該模塊錯誤的引入了你的模塊，而不是 stdlib 中的模塊。這就會出問題了。
因此，我們必須要注意這個問題，以避免使用和Python標準庫中相同的模塊名。修改你包中的模塊名要比通過 Python Enhancement Proposal (PEP) 給Python提建議來修改標準庫的模塊名容易多了。 |
頂 翻譯的不錯哦!
|
常見錯誤 #9: 未能解決Python 2和Python 3之間的差異
請看下面這個 filefoo.py:
15 | except ValueError as e: |
在Python 2中運行正常：
但是，現(xiàn)在讓我們把它在Python 3中運行一下：
3 | Traceback (most recent call last): |
4 | File "foo.py", line 19, in <module> |
6 | File "foo.py", line 17, in bad |
8 | UnboundLocalError: local variable 'e' referenced before assignment |
出什么問題了？ “問題”就是，在 Python 3 中，異常的對象在 except 代碼塊之外是不可見的。（這樣做的原因是，它將保存一個對內(nèi)存中堆棧幀的引用周期，直到垃圾回收器運行并且從內(nèi)存中清除掉引用。了解更多技術細節(jié)請參考這里） 。
一種解決辦法是在 except 代碼塊的外部作用域中定義一個對異常對象的引用，以便訪問。下面的例子使用了該方法，因此最后的代碼可以在Python 2 和 Python 3中運行良好。
14 | except ValueError as e: |
在Py3k中運行:
正常!
(順便提一下, 我們的 Python Hiring Guide 討論了當我們把代碼從Python 2 遷移到 Python 3時的其他一些需要知道的重要差異。) |
頂 翻譯的不錯哦!
|
常見錯誤 #10: 誤用__del__方法
假設你有一個名為 calledmod.py 的文件：
6 | foo.cleanup(self.myhandle) |
并且有一個名為 another_mod.py 的文件：
你會得到一個 AttributeError 的異常。
為什么呢？因為，正如這里所說，當解釋器退出的時候，模塊中的全局變量都被設置成了 None。所以，在上面這個例子中，當 __del__ 被調(diào)用時，foo 已經(jīng)被設置成了None。
解決方法是使用 atexit.register() 代替。用這種方式，當你的程序結束執(zhí)行時（意思是正常退出），你注冊的處理程序會在解釋器退出之前執(zhí)行。
了解了這些，我們可以將上面 mod.py 的代碼修改成下面的這樣：
11 | atexit.register(cleanup, self.myhandle) |
這種實現(xiàn)方式提供了一個整潔并且可信賴的方法用來在程序退出之前做一些清理工作。很顯然，它是由foo.cleanup 來決定對綁定在 self.myhandle 上對象做些什么處理工作的，但是這就是你想要的。 |
頂 翻譯的不錯哦!
|
總結
Python是一門強大的并且很靈活的語言，它有很多機制和語言規(guī)范來顯著的提高你的生產(chǎn)力。和其他任何一門語言或軟件一樣，如果對它能力的了解有限，這很可能會給你帶來阻礙，而不是好處。正如一句諺語所說的那樣 “knowing enough to be dangerous”（譯者注：意思是自以為已經(jīng)了解足夠了，可以做某事了，但其實不是）。
熟悉Python的一些關鍵的細微之處，像本文中所提到的那些（但不限于這些），可以幫助我們更好的去使用語言，從而避免一些常見的陷阱。
你可以查看“Python 面試官指南” 來獲得一些關于如何辨別一個開發(fā)者是否是Python專家的建議。
我們希望你在這篇文章中找到了一些對你有幫助的東西，并希望你得到你的反饋。 | |
