常見錯誤1：在函數參數中亂用表達式作為默認值
Python允許給一個函數的某個參數設置默認值以使該參數成為一個可選參數。盡管這是這門語言很棒的一個功能，但是這當這個默認值是可變對象（mutable）時，那就有些麻煩了。例如，看下面這個Python函數定義：
|
1
2
3
|
>>>
def
foo(bar
=
[]):
# bar是可選參數，如果沒有指明的話，默認值是[]
... bar.append(
"baz"
)
# 但是這行可是有問題的，走着瞧…
...
return
bar
|
人們常犯的一個錯誤是認為每次調用這個函數時不給這個可選參數賦值的話，它總是會被賦予這個默認表達式的值。例如，在上面的代碼中，程序員可能會認為重復調用函數foo() （不傳參數bar給這個函數），這個函數會總是返回‘baz’，因為我們假定認為每次調用foo()的時候（不傳bar），參數bar會被置為[]（即，一個空的列表）。
那么我們來看看這么做的時候究竟會發生什么：
|
1
2
3
4
5
6
|
>>> foo()
[
"baz"
]
>>> foo()
[
"baz"
,
"baz"
]
>>> foo()
[
"baz"
,
"baz"
,
"baz"
]
|
嗯？為什么每次調用foo()的時候，這個函數總是在一個已經存在的列表后面添加我們的默認值“baz”，而不是每次都創建一個新的列表？
答案是一個函數參數的默認值，僅僅在該函數定義的時候，被賦值一次。如此，只有當函數foo()第一次被定義的時候，才講參數bar的默認值初始化到它的默認值（即一個空的列表）。當調用foo()的時候（不給參數bar），會繼續使用bar最早初始化時的那個列表。
由此，可以有如下的解決辦法：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
>>>
def
foo(bar
=
None
):
...
if
bar
is
None
:
# 或者用 if not bar:
... bar
=
[]
... bar.append(
"baz"
)
...
return
bar
...
>>> foo()
[
"baz"
]
>>> foo()
[
"baz"
]
>>> foo()
[
"baz"
]
|
常見錯誤2：不正確的使用類變量
看下面一個例子：
|
1
2
3
4
5
6
7
8
9
10
11
|
>>>
class
A(
object
):
... x
=
1
...
>>>
class
B(A):
...
pass
...
>>>
class
C(A):
...
pass
...
>>>
print
A.x, B.x, C.x
1
1
1
|
看起來沒有問題。
|
1
2
3
|
>>> B.x
=
2
>>>
print
A.x, B.x, C.x
1
2
1
|
嗯哈，還是和預想的一樣。
|
1
2
3
|
>>> A.x
=
3
>>>
print
A.x, B.x, C.x
3
2
3
|
我了個去。只是改變了A.x，為啥C.x也變了？
在Python里，類變量通常在內部被當做字典來處理並遵循通常所說的方法解析順序（Method Resolution Order (MRO)）。因此在上面的代碼中，因為屬性x在類C中找不到，因此它會往上去它的基類中查找（在上面的例子中只有A這個類，當然Python是支持多重繼承（multiple inheritance）的）。換句話說，C沒有它自己獨立於A的屬性x。因此對C.x的引用實際上是對A.x的引用。（B.x不是對A.x的引用是因為在第二步里B.x=2將B.x引用到了2這個對象上，倘若沒有如此，B.x仍然是引用到A.x上的。——譯者注）
常見錯誤3：在異常處理時錯誤的使用參數
假設你有如下的代碼：
|
1
2
3
4
5
6
7
8
9
|
>>>
try
:
... l
=
[
"a"
,
"b"
]
...
int
(l[
2
])
...
except
ValueError, IndexError:
# 想捕捉兩個異常
...
pass
...
Traceback (most recent call last):
File
"<stdin>"
, line
3
,
in
<module>
IndexError:
list
index out of
range
|
這里的問題在於except語句不會像這樣去接受一系列的異常。並且，在Python 2.x里面，語法except Exception, e是用來將異常和這個可選的參數綁定起來（即這里的e），以用來在后面查看的。因此，在上面的代碼中，IndexError異常不會被except語句捕捉到；而最終ValueError這個異常被綁定在了一個叫做IndexError的參數上。
在except語句中捕捉多個異常的正確做法是將所有想要捕捉的異常放在一個元組（tuple）里並作為第一個參數給except語句。並且，為移植性考慮，使用as關鍵字，因為Python 2和Python 3都支持這樣的語法，例如：
|
1
2
3
4
5
6
7
|
>>>
try
:
... l
=
[
"a"
,
"b"
]
...
int
(l[
2
])
...
except
(ValueError, IndexError) as e:
...
pass
...
>>>
|
常見錯誤4：誤解Python作用域的規則
Python的作用域解析是基於叫做LEGB（Local（本地），Enclosing（封閉），Global（全局），Built-in（內置））的規則進行操作的。這看起來很直觀，對吧？事實上，在Python中這有一些細微的地方很容易出錯。看這個例子：
|
1
2
3
4
5
6
7
8
9
10
|
>>> x
=
10
>>>
def
foo():
... x
+
=
1
...
print
x
...
>>> foo()
Traceback (most recent call last):
File
"<stdin>"
, line
1
,
in
<module>
File
"<stdin>"
, line
2
,
in
foo
UnboundLocalError: local variable
'x'
referenced before assignment
|
這是怎么回事？
這是因為，在一個作用域里面給一個變量賦值的時候，Python自動認為這個變量是這個作用域的本地變量，並屏蔽作用域外的同名的變量。
很多時候可能在一個函數里添加一個賦值的語句會讓你從前本來工作的代碼得到一個UnboundLocalError。（感興趣的話可以讀一讀這篇文章。）
在使用列表（lists）的時候，這種情況尤為突出。看下面這個例子：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
>>> lst
=
[
1
,
2
,
3
]
>>>
def
foo1():
... lst.append(
5
)
# 這沒有問題...
...
>>> foo1()
>>> lst
[
1
,
2
,
3
,
5
]
>>> lst
=
[
1
,
2
,
3
]
>>>
def
foo2():
... lst
+
=
[
5
]
# ... 這就有問題了！
...
>>> foo2()
Traceback (most recent call last):
File
"<stdin>"
, line
1
,
in
<module>
File
"<stdin>"
, line
2
,
in
foo
UnboundLocalError: local variable
'lst'
referenced before assignment
|
嗯？為什么foo2有問題，而foo1沒有問題？
答案和上一個例子一樣，但是更加不易察覺。foo1並沒有給lst賦值，但是foo2嘗試給lst賦值。注意lst+=[5]只是lst=lst+[5]的簡寫，由此可以看到我們嘗試給lst賦值（因此Python假設作用域為本地）。但是，這個要賦給lst的值是基於lst本身的（這里的作用域仍然是本地），而lst卻沒有被定義，這就出錯了。
常見錯誤5：在遍歷列表的同時又在修改這個列表
下面這個例子中的代碼應該比較明顯了：
|
1
2
3
4
5
6
7
8
9
|
>>> 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]
# 這不對的：在遍歷列表時刪掉列表的元素。
...
Traceback (most recent call last):
File
"<stdin>"
, line
2
,
in
<module>
IndexError:
list
index out of
range
|
遍歷一個列表或者數組的同時又刪除里面的元素，對任何有經驗的軟件開發人員來說這是個很明顯的錯誤。但是像上面的例子那樣明顯的錯誤，即使有經驗的程序員也可能不經意間在更加復雜的程序中不小心犯錯。
所幸，Python集成了一些優雅的編程范式，如果使用得當，可以寫出相當簡化和精簡的代碼。一個附加的好處是更簡單的代碼更不容易遇到這種“不小心在遍歷列表時刪掉列表元素”的bug。例如列表推導式（list comprehensions）就提供了這樣的范式。再者，列表推導式在避免這樣的問題上特別有用，接下來這個對上面的代碼的重新實現就相當完美：
|
1
2
3
4
5
|
>>> odd
=
lambda
x :
bool
(x
%
2
)
>>> numbers
=
[n
for
n
in
range
(
10
)]
>>> numbers[:]
=
[n
for
n
in
numbers
if
not
odd(n)]
# 啊，這多優美
>>> numbers
[
0
,
2
,
4
,
6
,
8
]
|
常見錯誤6：搞不清楚在閉包（closures）中Python是怎樣綁定變量的
看這個例子：
|
1
2
3
4
5
|
>>>
def
create_multipliers():
...
return
[
lambda
x : i
*
x
for
i
in
range
(
5
)]
>>>
for
multiplier
in
create_multipliers():
...
print
multiplier(
2
)
...
|
期望得到下面的輸出：
|
1
2
3
4
5
|
0
2
4
6
8
|
但是實際上得到的是：
|
1
2
3
4
5
|
8
8
8
8
8
|
意外吧！
這是由於Python的后期綁定（late binding）機制導致的，這是指在閉包中使用的變量的值，是在內層函數被調用的時候查找的。因此在上面的代碼中，當任一返回函數被調用的時候，i的值是在它被調用時的周圍作用域中查找（到那時，循環已經結束了，所以i已經被賦予了它最終的值4）。
解決的辦法比較巧妙：
|
1
2
3
4
5
6
7
8
9
10
11
|
>>>
def
create_multipliers():
...
return
[
lambda
x, i
=
i : i
*
x
for
i
in
range
(
5
)]
...
>>>
for
multiplier
in
create_multipliers():
...
print
multiplier(
2
)
...
0
2
4
6
8
|
這下對了！這里利用了默認參數去產生匿名函數以達到期望的效果。有人會說這很優美，有人會說這很微妙，也有人會覺得反感。但是如果你是一名Python程序員，重要的是能理解任何的情況。
常見錯誤7：循環加載模塊
假設你有兩個文件，a.py和b.py，在這兩個文件中互相加載對方，例如：
在a.py中：
|
1
2
3
4
|
import
b
def
f():
return
b.x
print
f()
|
在b.py中：
|
1
2
3
4
|
import
a
x
=
1
def
g():
print
a.f()
|
首先，我們試着加載a.py：
|
1
2
|
>>>
import
a
1
|
沒有問題。也許讓人吃驚，畢竟有個感覺應該是問題的循環加載在這兒。
事實上在Python中僅僅是表面上的出現循環加載並不是什么問題。如果一個模塊以及被加載了，Python不會傻到再去重新加載一遍。但是，當每個模塊都想要互相訪問定義在對方里的函數或者變量時，問題就來了。
讓我們再回到之前的例子，當我們加載a.py時，它再加載b.py不會有問題，因為在加載b.py時，它並不需要訪問a.py的任何東西，而在b.py中唯一的引用就是調用a.f()。但是這個調用是在函數g()中完成的，並且a.py或者b.py中沒有人調用g()，所以這會兒心情還是美麗的。
但是當我們試圖加載b.py時（之前沒有加載a.py），會發生什么呢：
|
1
2
3
4
5
6
7
8
9
10
|
>>>
import
b
Traceback (most recent call last):
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的過程中，Python試圖加載a.py，並且在a.py中需要調用到f()，而函數f()又要訪問到b.x，但是這個時候b.x卻還沒有被定義。這就產生了AttributeError異常。
解決的方案可以做一點細微的改動。改一下b.py，使得它在g()里面加載a.py：
|
1
2
3
4
|
x
=
1
def
g():
import
a
# 只有當g()被調用的時候才加載
print
a.f()
|
這會兒當我們加載b.py的時候，一切安好：
|
1
2
3
4
|
>>>
import
b
>>> b.g()
1
# 第一次輸出，因為模塊a在最后調用了‘print f()’
1
# 第二次輸出，這是我們調用g()
|
常見錯誤8：與Python標准庫模塊命名沖突
Python的一個優秀的地方在於它提供了豐富的庫模塊。但是這樣的結果是，如果你不下意識的避免，很容易你會遇到你自己的模塊的名字與某個隨Python附帶的標准庫的名字沖突的情況（比如，你的代碼中可能有一個叫做email.py的模塊，它就會與標准庫中同名的模塊沖突）。
這會導致一些很粗糙的問題，例如當你想加載某個庫，這個庫需要加載Python標准庫里的某個模塊，結果呢，因為你有一個與標准庫里的模塊同名的模塊，這個包錯誤的將你的模塊加載了進去，而不是加載Python標准庫里的那個模塊。這樣一來就會有麻煩了。
所以在給模塊起名字的時候要小心了，得避免與Python標准庫中的模塊重名。相比起你提交一個“Python改進建議（Python Enhancement Proposal (PEP)）”去向上要求改一個標准庫里包的名字，並得到批准來說，你把自己的那個模塊重新改個名字要簡單得多。
常見錯誤9：不能區分Python 2和Python 3
看下面這個文件foo.py：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
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里，運行起來沒有問題：
|
1
2
3
4
5
6
|
$ python foo.py
1
key error
1
$ python foo.py
2
value error
2
|
但是如果拿到Python 3上面玩玩：
|
1
2
3
4
5
6
7
8
|
$ python3 foo.py
1
key error
Traceback (most recent call last):
File
"foo.py"
, line
19
,
in
<module>
bad()
File
"foo.py"
, line
17
,
in
bad
print(e)
UnboundLocalError: local
var
iable
'e'
referenced before assignment
|
這是怎么回事？“問題”在於，在Python 3里，在except塊的作用域以外，異常對象（exception object）是不能被訪問的。（原因在於，如果不這樣的話，Python會在內存的堆棧里保持一個引用鏈直到Python的垃圾處理將這些引用從內存中清除掉。更多的技術細節可以參考這里。）
避免這樣的問題可以這樣做：保持在execpt塊作用域以外對異常對象的引用，這樣是可以訪問的。下面是用這個辦法對之前的例子做的改動，這樣在Python 2和Python 3里面都運行都沒有問題。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
import
sys
def
bar(i):
if
i
=
=
1
:
raise
KeyError(
1
)
if
i
=
=
2
:
raise
ValueError(
2
)
def
good():
exception
=
None
try
:
bar(
int
(sys.argv[
1
]))
except
KeyError as e:
exception
=
e
print
(
'key error'
)
except
ValueError as e:
exception
=
e
print
(
'value error'
)
print
(exception)
good()
|
在Py3k里面運行：
|
1
2
3
4
5
6
|
$ python3 foo.py
1
key error
1
$ python3 foo.py
2
value error
2
|
耶！
（順帶提一下，我們的“Python招聘指南”里討論了從Python 2移植代碼到Python 3時需要注意的其他重要的不同之處。）
常見錯誤10：錯誤的使用__del__方法
假設有一個文件mod.py中這樣使用：
|
1
2
3
4
5
6
|
import
foo
class
Bar(
object
):
...
def
__del__(
self
):
foo.cleanup(
self
.myhandle)
|
然后試圖在another_mod.py里這樣：
|
1
2
|
import
mod
mybar
=
mod.Bar()
|
那么你會得到一個惡心的AttributeError異常。
為啥呢？這是因為（參考這里），當解釋器關閉時，模塊所有的全局變量會被置為空（None）。結果便如上例所示，當__del__被調用時，名字foo已經被置為空了。
使用atexit.register()可以解決這個問題。如此，當你的程序結束的時候（退出的時候），你的注冊的處理程序會在解釋器關閉之前處理。
這樣理解的話，對上面的mod.py可以做如下的修改：
|
1
2
3
4
5
6
7
8
9
10
|
import
foo
import
atexit
def
cleanup(handle):
foo.cleanup(handle)
class
Bar(
object
):
def
__init__(
self
):
...
atexit.register(cleanup,
self
.myhandle)
|