Introduction

本文介紹python程式設計中常見的錯誤的陷阱

潛在的Python陷阱

沉迷於一行程式

許多人熱衷於一行程式帶來的興奮感。即使他們的一行解決方案比一個多行解決方案低效，他們也會吹噓。

Python中的一行程式在本質上意味著具有多個表示式的複雜推導。例如：

很多人都寫類似的程式碼。這樣的程式碼在一個星期後就會變得難以理解。如果你想做一些稍微複雜的事情，例如根據條件簡單地在一個列表或集合中新增一個元素，你可能就會犯錯誤。

單行程式碼並不是什麼成就，是的，他們可能看起來很靈活，但不是什麼成就。想象一下，這就像是你在打掃房間時把所有的東西都塞進你的衣櫥。好的程式碼應該是乾淨的，易於閱讀的和高效的。

利用錯誤的方式初始化一個集合

這是一個更微妙的問題，可能讓你措手不及。集合推導很像列表推導。

上面就是集合推導的一個例子。集合就像列表，也是一個容器。所不同的是，一個集合中不能有任何重複的值，而且是無序的。看到集合推導人們經常錯誤地認為{}能初始化一個空集合。但其實不然，它初始化一個空字典。

如果你想初始化一個空集合，可以簡單地呼叫set()方法。

注意一個空集合用set()表示，但是一個包含一些元素的集合就就要用花括號包圍元素來表示。

這和直覺是相反的，因為你期望類似於set([1, 2])的一些東西。

誤解GIL

GIL（全域性直譯器鎖）意味著在Python程式中，任意一個時間點只能有一個執行緒在執行。這意味著當我們建立一個執行緒並希望它並行執行時，它並不會那樣。Python直譯器實際的工作是在不同的執行執行緒之間快速進行切換。但這只是對實際發生事情的一個非常簡單的解釋，實際情況要複雜的多。有很多種並行執行的例項，例如使用本質為C擴充套件的各種庫。但執行Python程式碼時，大部分時間裡它不會並行執行。換句話說，Python中的執行緒並不像Java或C++中的執行緒。

許多人會嘗試為Python辯解，說這些都是真正的執行緒。這確實是真的，但並不能改變這樣一個事實：Python處理執行緒的方式和你期望的方式是不同的。Ruby語言也有相同的情況（Ruby也有一個直譯器鎖）。

指定的解決方案是使用multiprocessing模組。multiprocessing模組提供Process類，它是一個對fork的很好的覆蓋。然而，fork過程比一個執行緒的代價高得多，所以你可能不會每次都能看到效能上的提升，因為不同的process之間需要做大量的工作來進行相互協調。

然而，這個問題並不存在於每一個Python的實現版本中。例如，Python的一個實現PyPy-stm就試圖擺脫GIL（仍未穩定）。建立在其他平臺，如JVM（Jython）或CLR（IronPython），上的Python實現，也沒有GIL的問題。

總之，使用Thread類時要多加小心，你得到的可能不是你想要的。

使用老式類

在Python 2中，有兩種型別的類，分別為“老式”類和“新式”類。如果你使用Python 3，那麼你預設使用“新式”類。為了確保在Python2中使用“新式”類，你需要讓你新建立的每一個類都繼承object類，且類不能已繼承了內建型別，例如int或list。換句話說，你的基類、類如果不繼承其他類，就總是需要繼承object類。

這些“新式”類解決一些老式類的根本缺陷，這一點我們不需要深入瞭解。然而，如果有人感興趣，他們可以在相關文件中找到相關資訊。

使用可變的預設引數

我多次見到過如下的程式碼：

永遠不要使用可變的預設引數，可以使用如下的程式碼代替：

與其解釋這個問題是什麼，不如展示下使用可變預設引數的影響：

同一個變數c在函式呼叫的每一次都被反覆引用。這可能有一些意想不到的後果。

總結

這些只是相對來說剛接觸Python的人可能會遇到的一些問題。然而請注意，可能會遇到的問題遠非就這麼些。然而另一些缺陷是人們像使用Java或C++一樣使用Python，並且試圖按他們熟悉的方式使用Python。所以作為本篇文章的一個延續，嘗試深入一些東西，例如Python的super函式。看看類方法、靜態方法和 __slots__等。

10大最常見的Python程式設計錯誤 - Master the 10 Most Common Python Programming Problems

(Note: This article is intended for a more advanced audience than Common Mistakes of Python Programmers, which is geared(適合) more toward those who are newer to the language.)

Common Mistake #1: Misusing expressions as defaults for function arguments

Python allows you to specify(指定) that a function argument isoptional by providing adefault value for it. While this is a greatfeature(特色) of the language, it can lead to someconfusion(混淆) when the default value is. For example, consider this Python functiondefinition(定義):

>>> def foo(bar=[]):        # bar is optional and defaults to [] if not specified
...    bar.append("baz")    # but this line could be problematic, as we'll see...
...    return bar

A common mistake is to think that the optional(可選擇的) argument will be set to the specified default expressioneach time the function is called without supplying a value for the optional argument. In the above code, for example, one might expect that callingfoo() repeatedly (i.e., without specifying(指定) a bar argument) would always return 'baz', since the assumption(假定) would be thateach timefoo() is called (without a bar argument specified)bar is set to[] (i.e., a new empty list).

But let’s look at what actually happens when you do this:

>>> foo()
["baz"]
>>> foo()
["baz", "baz"]
>>> foo()
["baz", "baz", "baz"]

Huh? Why did it keep appending(附加) the default value of"baz" to anexisting list each time foo() was called, rather than creating anew list each time?

The more advanced Python programming answer is that the default value for a function argument is onlyevaluated(評價) once, at the time that the function isdefined(定義). Thus, thebar argument isinitialized(初始化) to its default (i.e., an empty list) only whenfoo() is first defined, but then calls tofoo() (i.e., without abar argument specified(規定的)) will continue to use the same list to whichbar was originally initialized.

FYI, a common workaround(工作區) for this is as follows:

>>> def foo(bar=None):
...    if bar is None:		# or if not bar:
...        bar = []
...    bar.append("baz")
...    return bar
...
>>> foo()
["baz"]
>>> foo()
["baz"]
>>> foo()
["baz"]

Common Mistake #2: Using classvariables(變數) incorrectly

Consider the following example:

>>> class A(object):
...     x = 1
...
>>> class B(A):
...     pass
...
>>> class C(A):
...     pass
...
>>> print A.x, B.x, C.x
1 1 1

Makes sense.

>>> B.x = 2
>>> print A.x, B.x, C.x
1 2 1

Yup, again as expected.

>>> A.x = 3
>>> print A.x, B.x, C.x
3 2 3

What the $%#!&?? We only changed A.x. Why did C.x change too?

In Python, class variables(變數) areinternally(內部地) handled as dictionaries and follow what is often referred to asMethod Resolution Order (MRO). So in the above code, since theattribute(屬性)x is not found in class C, it will be looked up in its base classes (onlyA in the above example, although Python supports multipleinheritance(繼承)). In other words,C doesn’t have its ownx property, independent of A. Thus, references(參考) toC.x are in fact references toA.x. This causes a Python problem unless it’s handled properly. Learn more aoutclassattributes(屬性) in Python.

Common Mistake #3: Specifying(指定) parameters(引數) incorrectly for anexception(例外) block

Suppose you have the following code:

>>> try:
...     l = ["a", "b"]
...     int(l[2])
... except ValueError, IndexError:  # To catch both exceptions, right?
...     pass
...
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
IndexError: list index out of range

The problem here is that the except statement does not take a list of exceptions specified in this manner. Rather, In Python 2.x, thesyntax(語法)except Exception, e is used to bind(綁) the exception to theoptional secondparameter(引數)specified(指定) (in this casee), in order to make it available for further inspection(視察). As a result, in the above code, theIndexError exception isnot being caught by the exceptstatement(宣告); rather, theexception(例外) instead ends up being bound to a parameter namedIndexError.

The proper way to catch multiple exceptions in an except statement is to specify the first parameter as atuple containing all exceptions to be caught. Also, for maximum portability(可移植性), use theas keyword, since thatsyntax(語法) is supported by both Python 2 and Python 3:

>>> try:
...     l = ["a", "b"]
...     int(l[2])
... except (ValueError, IndexError) as e:  
...     pass
...
>>>

Common Mistake #4: Misunderstanding Pythonscope(範圍) rules

Python(巨蟒) scoperesolution(解析度) is based on what is known as theLEGB rule, which isshorthand(速記法的) forLocal,Enclosing, Global, Built-in. Seemsstraightforward(簡單的) enough, right? Well, actually, there are somesubtleties(微妙) to the way this works in Python, which brings us to the common more advanced Python programming problem below. Consider the following:

>>> 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

What’s the problem?

The above error occurs because, when you make an assignment to a variable(變數的) in ascope(範圍),that variable isautomatically(自動地) considered by Python to be local to that scope and shadows any similarly named variable in any outer scope.

Many are thereby surprised to get an UnboundLocalError in previously working code when it ismodified(修改) by adding anassignment(分配)statement(宣告) somewhere in the body of a function. (You can read more about thishere.)

It is particularly common for this to trip up developers when using lists. Consider the following example:

>>> lst = [1, 2, 3]
>>> def foo1():
...     lst.append(5)   # This works ok...
...
>>> foo1()
>>> lst
[1, 2, 3, 5]

>>> lst = [1, 2, 3]
>>> def foo2():
...     lst += [5]      # ... but this bombs!
...
>>> 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

Huh? Why did foo2 bomb while foo1 ran fine?

The answer is the same as in the prior(優先的) example problem, but is admittedly moresubtle(微妙的).foo1 is not making an assignment to lst, whereasfoo2 is. Remembering thatlst += [5] is really just shorthand(速記法的) forlst = lst + [5], we see that we are attempting toassign a value tolst (therefore presumed(假定) by Python to be in the localscope(範圍)). However, the value we are looking toassign(分配) tolst is based onlst itself (again, now presumed to be in the local scope), which has not yet beendefined(定義).Boom(興旺).

Common Mistake #5: Modifying a list whileiterating(迭代) over it

The problem with the following code should be fairly obvious:

>>> 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
...
Traceback (most recent call last):
  	  File "<stdin>", line 2, in <module>
IndexError: list index out of range

Deleting an item from a list or array(陣列) while iterating over it is a Python problem that is well known to any experienced software developer. But while the example above may be fairly obvious, even advanced developers can be unintentionally(無意地) bitten by this in code that is much morecomplex(複雜的).

Fortunately, Python incorporates(包含) a number ofelegant(高雅的) programmingparadigms(範例) which, when used properly, can result insignificantly(意味深長地)simplified(簡化了的) andstreamlined(流線型的) code. A sidebenefit(利益) of this is that simpler code is less likely to be bitten by the accidental-deletion-of-a-list-item-while-iterating-over-it bug. One such paradigm is that oflist comprehensions. Moreover, list comprehensions(理解) are particularly useful for avoiding thisspecific(特殊的) problem, as shown by thisalternate(交替的)implementation(實現) of the above code which works perfectly:

>>> odd = lambda x : bool(x % 2)
>>> numbers = [n for n in range(10)]
>>> numbers[:] = [n for n in numbers if not odd(n)]  # ahh, the beauty of it all
>>> numbers
[0, 2, 4, 6, 8]

Common Mistake #6: Confusing how Pythonbinds(捆綁)variables(變數) inclosures(關閉)

Considering the following example:

>>> def create_multipliers():
...     return [lambda x : i * x for i in range(5)]
>>> for multiplier in create_multipliers():
...     print multiplier(2)
...

You might expect the following output(輸出):

0
2
4
6
8

But you actually get:

8
8
8
8
8

Surprise!

This happens due to Python’s late binding behavior(行為) which says that the values ofvariables(變數) used inclosures(關閉) are looked up at the time the inner function is called. So in the above code, whenever any of the returned functions are called, the value ofi is looked up in the surrounding scope(範圍) at the time it is called (and by then, theloop(環) has completed, soi has already been assigned(分配) its final value of 4).

The solution(解決方案) to this common Python problem is a bit of a hack:

>>> 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

Voilà! We are taking advantage of default arguments here to generate(形成) anonymous(匿名的) functions in order to achieve the desired behavior. Some would call thiselegant(高雅的). Some would call itsubtle(微妙的). Some hate it. But if you’re a Python developer, it’s important to understand in any case.

Common Mistake #7: Creatingcircular(通知) moduledependencies(依賴性)

Let’s say you have two files, a.py and b.py, each of which imports the other, as follows:

In a.py:

import b

def f():
    return b.x
	
print f()

And in b.py:

import a

x = 1

def g():
    print a.f()

First, let’s try importing a.py:

>>> import a
1

Worked just fine. Perhaps that surprises you. After all, we do have a circular(迴圈的) import here whichpresumably(大概) should be a problem, shouldn’t it?

The answer is that the mere(僅僅的)presence of a circular import is not in and of itself a problem in Python. If a module has already been imported, Python is smart enough not to try to re-import it. However, depending on the point at which each module is attempting to access functions orvariables(變數)defined(定義) in the other, you may indeed run into problems.

So returning to our example, when we imported a.py, it had no problem importingb.py, sinceb.py does not require anything from a.py to be definedat the time it is imported. The onlyreference(參考) inb.py toa is the call to a.f(). But that call is ing() and nothing ina.py or b.py invokes g(). So life is good.

But what happens if we attempt to import b.py (without having previously importeda.py, that is):

>>> 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'

Uh-oh(噢喔). That’s not good! The problem here is that, in the process of importingb.py, it attempts to importa.py, which in turn calls f(), which attempts to accessb.x. But b.x has not yet beendefined(定義).Hence(因此) theAttributeError exception.

At least one solution(解決方案) to this is quitetrivial(不重要的). Simplymodify(修改)b.py to importa.py within g():

x = 1

def g():
    import a	# This will be evaluated only when g() is called
    print a.f()

No when we import it, everything is fine:

>>> import b
>>> 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'

Common Mistake #8: Nameclashing(衝突) with Python Standard Library modules

One of the beauties of Python is the wealth of library modules that it comes with “out of the box”. But as a result, if you’re notconsciously(自覺地) avoiding it, it’s not that difficult to run into a name clash between the name of one of your modules and a module with the same name in the standard library that ships with Python (for example, you might have a module namedemail.py in your code, which would be in conflict(衝突) with the standard library module of the same name).

This can lead to gnarly(多瘤的) problems, such as importing another library which in turns tries to import the Python Standard Library version of a module but, since you have a module with the same name, the other package mistakenly imports your version instead of the one within the Python Standard Library. This is where bad Python errors happen.

Care should therefore be exercised to avoid using the same names as those in the Python Standard Library modules. It’s way easier for you to change the name of a module within your package than it is to file aPython(巨蟒) Enhancement Proposal (PEP) to request a name changeupstream(上游部門) and to try and get thatapproved(批准).

Common Mistake #9: Failing to address differences between Python 2 and Python 3

Consider the following file foo.py:

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()

On Python 2, this runs fine:

$ python foo.py 1
key error
1
$ python foo.py 2
value error
2

But now let’s give it a whirl(旋轉) on Python 3:

$ 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 variable 'e' referenced before assignment

What has just happened here? The “problem” is that, in Python 3, the exception(例外) object is notaccessible(易接近的) beyond thescope(範圍) of theexcept block. (The reason for this is that, otherwise, it would keep areference(參考) cycle with thestack(堆)frame(框架) in memory until the garbagecollector(收藏家) runs andpurges(淨化) the references from memory. More technical detail about this is availablehere).

One way to avoid this issue is to maintain(維持) a reference(參考) to theexception(例外) objectoutside thescope(範圍) of theexcept block so that it remainsaccessible(易接近的). Here’s a version of the previous example that uses this technique, therebyyielding(屈服) code that is both Python 2 and Python 3 friendly:

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()

Running this on Py3k:

$ python3 foo.py 1
key error
1
$ python3 foo.py 2
value error
2

Yippee!

(Incidentally, our Python Hiring Guide discusses a number of other important differences to be aware(意識到的) of whenmigrating(移動) code from Python 2 to Python 3.)

Common Mistake #10: Misusing the__del__ method

Let’s say you had this in a file called mod.py:

import foo

class Bar(object):
   	    ...
    def __del__(self):
        foo.cleanup(self.myhandle)

And you then tried to do this from another_mod.py:

import mod
mybar = mod.Bar()

You’d get an ugly AttributeError exception.

Why? Because, as reported here, when the interpreter(解釋者) shuts down, the module’s globalvariables(變數) are all set toNone. As a result, in the above example, at the point that__del__ is invoked(呼叫), the namefoo has already been set toNone.

A solution(解決方案) to this somewhat more advanced Python programming problem would be to useatexit.register() instead. That way, when your program is finishedexecuting(實行) (when exiting normally, that is), your registered handlers are kicked offbefore the interpreter is shut down.

With that understanding, a fix for the above mod.py code might then look something like this:

import foo
import atexit

def cleanup(handle):
    foo.cleanup(handle)


class Bar(object):
    def __init__(self):
        ...
        atexit.register(cleanup, self.myhandle)

This implementation(實現) provides a clean andreliable(可靠的) way of calling any neededcleanup(第四位擊球員的)functionality(功能) upon normal programtermination(結束). Obviously, it’s up tofoo.cleanup to decide what to do with the object bound to the nameself.myhandle, but you get the idea.

Wrap-up

Python is a powerful andflexible(靈活的) language with manymechanisms(機制) andparadigms(範例) that can greatly improveproductivity(生產力). As with any software tool or language, though, having a limited understanding orappreciation(欣賞) of itscapabilities(才能) can sometimes be more of animpediment(口吃) than abenefit(利益), leaving one in theproverbial(諺語的) state of “knowing enough to be dangerous”.

Familiarizing(熟悉) oneself with the keynuances(細微差別) of Python, such as (but by no means limited to) themoderately(適度地) advanced programming problems raised in this article, will helpoptimize(最優化) use of the language while avoiding some of its more common errors.

You might also want to check out our Insider’s Guide to Python Interviewing for suggestions on interview questions that can helpidentify(確定) Python experts.