常見錯誤1：錯誤地将表達式作為函數的預設參數
在python中，我們可以為函數的某個參數設定預設值，使該參數成為可選參數。雖然這是一個很好的語言特性，但是當預設值是可變類型時，也會導緻一些令人困惑的情況。我們來看看下面這個python函數定義：
>>> def foo(bar=[]): # bar是可選參數，如果沒有提供bar的值，則預設為[]，
... bar.append("baz") # 但是稍後我們會看到這行代碼會出現問題。
... return bar
python程式員常
犯的一個錯誤，就是想當然地認為：在每次調用函數時，如果沒有為可選參數傳入值，那麼這個可選參數就會被設定為指定的預設值。在上面的代碼中，你們可能覺
得重複調用foo()函數應該會一直傳回’baz’，因為你們預設每次foo()函數執行時（沒有指定bar變量的值），bar變量都被設定為[]（也就
是，一個新的空清單）。
但是，實際運作結果卻是這樣的：
>>> foo()
["baz"]
["baz", "baz"]
["baz", "baz", "baz"]
很奇怪吧？為什麼每次調用foo()函數時，都會把”baz”這個預設值添加到已有的清單中，而不是重新建立一個新的空清單呢？
答案就是，可選參數預設值的設定在python中隻會被執行一次，也就是定義該函數的時候。是以，隻有當foo()函數被定義時，bar參數才會被初始化為預設值（也就是，一個空清單），但是之後每次foo()函數被調用時，都會繼續使用bar參數原先初始化生成的那個清單。
當然，一個常見的解決辦法就是：
>>> def foo(bar=none):
... if bar is none: # or if not bar:
... bar = []
... bar.append("baz")
...
常見問題2：錯誤地使用類變量
我們來看下面這個例子：
>>> class a(object):
... x = 1
>>> class b(a):
... pass
>>> class c(a):
>>> print a.x, b.x, c.x
1 1 1
這個結果很正常。
>>> b.x = 2
1 2 1
嗯，結果和預計的一樣。
>>> a.x = 3
3 2 3
在python語言中，類變量是以字典的形式進行處理的，并且遵循方法解析順序（method resolution
order，mro）。是以，在上面的代碼中，由于類c中并沒有x這個屬性，解釋器将會查找它的基類（base
class，盡管python支援多重繼承，但是在這個例子中，c的基類隻有a）。換句話說，c并不沒有獨立于a、真正屬于自己的x屬性。是以，引用
c.x實際上就是引用了a.x。如果沒有處理好這裡的關系，就會導緻示例中出現的這個問題。
常見錯誤3：錯誤地指定異常代碼塊（exception block）的參數
請看下面這段代碼：
>>> try:
... l = ["a", "b"]
... int(l[2])
... except valueerror, indexerror: # to catch both exceptions, right?
traceback (most recent call last):
file "<stdin>", line 3, in <module>
indexerror: list index out of range
這段代碼的問題在于，except語句并不支援以這種方式指定異常。在python
2.x中，需要使用變量e将異常綁定至可選的第二個參數中，才能進一步檢視異常的情況。是以，在上述代碼中，except語句并沒有捕獲
indexerror異常；而是将出現的異常綁定到了一個名為indexerror的參數中。
要想在except語句中正确地捕獲多個異常，則應将第一個參數指定為元組，然後在元組中寫下希望捕獲的異常類型。另外，為了提高可移植性，請使用as關鍵詞，python 2和python 3均支援這種用法。
... except (valueerror, indexerror) as e:
>>>
常見錯誤4：錯誤了解python中的變量名解析
python中的變量名解析遵循所謂的legb原則，也就是“l：本地作用域；e：上一層結構中def或lambda的本地作用域；g：全局作用
域；b：内置作用域”（local，enclosing，global，builtin），按順序查找。看上去是不是很簡單？不過，事實上這個原則的生效
方式還是有着一些特殊之處。說到這點，我們就不得不提下面這個常見的python程式設計錯誤。請看下面的代碼：
>>> x = 10
>>> def foo():
... x += 1
... print x
file "<stdin>", line 1, in <module>
file "<stdin>", line 2, in foo
unboundlocalerror: local variable 'x' referenced before assignment
出了什麼問題？
上述錯誤的出現，是因為當你在某個作用域内為變量指派時，該變量被python解釋器自動視作該作用域的本地變量，并會取代任何上一層作用域中相同名稱的變量。
正是因為這樣，才會出現一開始好好的代碼，在某個函數内部添加了一個指派語句之後卻出現了unboundlocalerror，難怪會讓許多人吃驚。
在使用清單時，python程式員尤其容易陷入這個圈套。
請看下面這個代碼示例：
>>> lst = [1, 2, 3]
>>> def foo1():
... lst.append(5) # 這裡沒問題
>>> foo1()
>>> lst
[1, 2, 3, 5]
>>> def foo2():
... lst += [5] # ... 但這裡就不對了!
>>> foo2()
unboundlocalerror: local variable 'lst' referenced before assignment
呃？為什麼函數foo1運作正常，foo2卻出現了錯誤？
答案與上一個示例相同，但是卻更難捉摸清楚。foo1函數并沒有為lst變量進行指派，但是foo2卻有指派。我們知道，lst +=
[5]隻是lst = lst +
[5]的簡寫，從中我們就可以看出，foo2函數在嘗試為lst指派（是以，被python解釋器認為是函數本地作用域的變量）。但是，我們希望為lst
賦的值卻又是基于lst變量本身（這時，也被認為是函數本地作用域内的變量），也就是說該變量還沒有被定義。這才出現了錯誤。
常見錯誤5：在周遊清單時更改清單
下面這段代碼的問題應該算是十分明顯：
>>> odd = lambda x : bool(x % 2)
>>> numbers = [n for n in range(10)]
>>> for i in range(len(numbers)):
... if odd(numbers[i]):
... del numbers[i] # bad: deleting item from a list while iterating over it
file "<stdin>", line 2, in <module>
在周遊清單或數組的同時從中删除元素，是任何經驗豐富的python開發人員都會注意的問題。但是盡管上面的示例十分明顯，資深開發人員在編寫更為複雜代碼的時候，也很可能會無意之下犯同樣的錯誤。
幸運的是，python語言融合了許多優雅的程式設計範式，如果使用得當，可以極大地簡化代碼。簡化代碼還有一個好處，就是不容易出現在周遊清單時删除
元素這個錯誤。能夠做到這點的一個程式設計範式就是清單解析式。而且，清單解析式在避免這個問題方面尤其有用，下面用清單解析式重新實作上面代碼的功能：
>>> numbers[:] = [n for n in numbers if not odd(n)] # ahh, the beauty of it all
>>> numbers
[0, 2, 4, 6, 8]
>>> def create_multipliers():
... return [lambda x : i * x for i in range(5)]
>>> for multiplier in create_multipliers():
... print multiplier(2)
你可能覺得輸出結果應該是這樣的：
2
4
6
8
但是，實際的輸出結果卻是：
吓了一跳吧！
這個結果的出現，主要是因為python中的遲綁定（late
binding）機制，即閉包中變量的值隻有在内部函數被調用時才會進行查詢。是以，在上面的代碼中，每次create_multipliers()所返
回的函數被調用時，都會在附近的作用域中查詢變量i的值（而到那時，循環已經結束，是以變量i最後被賦予的值為4）。
要解決這個常見python問題的方法中，需要使用一些hack技巧：
... return [lambda x, i=i : i * x for i in range(5)]
2
4
6
8
請注意！我們在這裡利用了預設參數來實作這個lambda匿名函數。有人可能認為這樣做很優雅，有人會覺得很巧妙，還有人會嗤之以鼻。但是，如果你是一名python程式員，不管怎樣你都應該要了解這種解決方法。
常見錯誤7：子產品之間出現循環依賴（circular dependencies）
假設你有兩個檔案，分别是a.py和b.py，二者互相引用，如下所示：
a.py檔案中的代碼:
import b
def f():
return b.x
print f()
b.py檔案中的代碼：
import a
x = 1
def g():
print a.f()
首先，我們嘗試導入a.py子產品：
>>> import a
1
代碼運作正常。也許這出乎了你的意料。畢竟，我們這裡存在循環引用這個問題，想必應該是會出現問題的，難道不是嗎？
答案是，僅僅存在循環引用的情況本身并不會導緻問題。如果一個子產品已經被引用了，python可以做到不再次進行引用。但是如果每個子產品試圖通路其他子產品定義的函數或變量的時機不對，那麼你就很可能陷入困境。
那麼回到我們的示例，當我們導入a.py子產品時，它在引用b.py子產品時是不會出現問題的，因為b.py子產品在被引用時，并不需要通路在a.py模
塊中定義的任何變量或函數。b.py子產品中對a子產品唯一的引用，就是調用了a子產品的foo()函數。但是那個函數調用發生在g()函數當中，而a.py或
b.py子產品中都沒有調用g()函數。是以，不會出現問題。
但是，如果我們試着導入b.py子產品呢（即之前沒有引用a.py子產品的前提下）：
>>> import b
file "<stdin>", line 1, in <module>
file "b.py", line 1, in <module>
import a
file "a.py", line 6, in <module>
print f()
file "a.py", line 4, in f
return b.x
attributeerror: 'module' object has no attribute 'x'
糟糕。情況不太妙！這裡的問題是，在導入b.py的過程中，它試圖引用a.py子產品，而a.py子產品接着又要調用foo()函數，這個foo()函數接着又試圖去通路b.x變量。但是這個時候，b.x變量還沒有被定義，是以才出現了attributeerror異常。
解決這個問題有一種非常簡單的方法，就是簡單地修改下b.py子產品，在g()函數内部才引用a.py：
import a # this will be evaluated only when g() is called
現在我們再導入b.py子產品的話，就不會出現任何問題了：
>>> b.g()
1 # printed a first time since module 'a' calls 'print f()' at the end
1 # printed a second time, this one is our call to 'g'
常見錯誤8：子產品命名與python标準庫子產品名沖突
python語言的一大優勢，就是其本身自帶的強大标準庫。但是，正因為如此，如果你不去刻意注意的話，你也是有可能為自己的子產品取一個和
python自帶标準庫子產品相同的名字（例如，如果你的代碼中有一個子產品叫email.py，那麼這就會與python标準庫中同名的子產品相沖突。）
這很可能會給你帶來難纏的問題。舉個例子，在導入子產品a的時候，假如該子產品a試圖引用python标準庫中的子產品b，但卻因為你已經有了一個同名子產品b，子產品a會錯誤地引用你自己代碼中的子產品b，而不是python标準庫中的子產品b。這也是導緻一些嚴重錯誤的原因。
是以，python程式員要格外注意，避免使用與python标準庫子產品相同的名稱。畢竟，修改自己子產品的名稱比提出pep提議修改上遊子產品名稱且讓提議通過，要來得容易的多。
常見錯誤9：未能解決python 2與python 3之間的差異
假設有下面這段代碼：
import sys
def bar(i):
if i == 1:
raise keyerror(1)
if i == 2:
raise valueerror(2)
def bad():
e = none
try:
bar(int(sys.argv[1]))
except keyerror as e:
print('key error')
except valueerror as e:
print('value error')
print(e)
bad()
如果是python 2，那麼代碼運作正常：
$ python foo.py 1
key error
1
$ python foo.py 2
value error
但是現在，我們換成python 3再運作一遍：
$ python3 foo.py 1
file "foo.py", line 19, in <module>
bad()
file "foo.py", line 17, in bad
unboundlocalerror: local variable 'e' referenced before assignment
這到底是怎麼回事？這裡的“問題”是，在python 3中，異常對象在except代碼塊作用域之外是無法通路的。（這麼設計的原因在于，如果不這樣的話，堆棧幀中就會一直保留它的引用循環，直到垃圾回收器運作，将引用從記憶體中清除。）
避免這個問題的一種方法，就是在except代碼塊的作用域之外，維持一個對異常對象的引用（reference），這樣異常對象就可以通路了。下面這段代碼就使用了這種方法，是以在python 2和python 3中的輸出結果是一緻的：
def good():
exception = none
exception = e
print(exception)
good()
在python 3下運作代碼：
$ python3 foo.py 2
太棒了！
常見錯誤10：錯誤使用del方法
假設你在mod.py的檔案中編寫了下面的代碼：
import foo
class bar(object):
...
def __del__(self):
foo.cleanup(self.myhandle)
之後，你在another_mod.py檔案中進行如下操作：
import mod
mybar = mod.bar()
如果你運作another_mod.py子產品的話，将會出現attributeerror異常。
為什麼？因為當解釋器結束運作的時候，該子產品的全局變量都會被設定為none。是以，在上述示例中，當__del__方法被調用之前，foo已經被設定成了none。
要想解決這個有點棘手的python程式設計問題，其中一個辦法就是使用atexit.register()方法。這樣的話，當你的程式執行完成之後（即正常退出程式的情況下），你所指定的處理程式就會在解釋器關閉之前運作。
應用了上面這種方法，修改後的mod.py檔案可能會是這樣子的：
import atexit
def cleanup(handle):
foo.cleanup(handle)
def __init__(self):
atexit.register(cleanup, self.myhandle)
這種實作支援在程式正常終止時幹淨利落地調用任何必要的清理功能。很明顯，上述示例中将會由foo.cleanup函數來決定如何處理self.myhandle所綁定的對象。
綜述
python是一門強大而又靈活的程式設計語言，提供的許多程式設計機制和範式可以極大地提高工作效率。
但是與任何軟體工具或語言一樣，如果對該語言的能力了解有限或無法欣賞，那麼有時候自己反而會被阻礙，而不是受益了。正如一句諺語所說，“自以為知道夠
多，但實則會給自己或别人帶來危險”（knowing enough to be
dangerous）。(譯者注:這句諺語的意思是，自以為已經對某件事情了解足夠，但在實際去執行或實施時，卻會給自己和别人帶來危險。)
不斷地熟悉python語言的一些細微之處，尤其是本文中提到的10大常見錯誤，将會幫助你有效地使用這門語言，同時也能避免犯一些比較常見的錯誤。
來源：51cto