Python常见编程错误和陷阱

我就是我 2022-08-07 17:43 241阅读 0赞

http://[blog.csdn.net/pipisorry/article/details/45175457][blog.csdn.net_pipisorry_article_details_45175457]

**Introduction**

本文介绍python编程中常见的错误的陷阱

**潜在的Python陷阱**

**沉迷于一行程序**

许多人热衷于一行程序带来的兴奋感。即使他们的一行解决方案比一个多行解决方案低效，他们也会吹嘘。

Python中的一行程序在本质上意味着具有多个表达式的复杂推导。例如：

l  =  \[ m  for  a ,  b  in  zip ( this ,  that )  if  b . method ( a )  !=  b  for  m  in  b  if  not  m . method ( a ,  b )  and  reduce ( lambda  x ,  y :  a  \+  y . method ( ) ,  ( m ,  a ,  b ) ) \]

很多人都写类似的代码。这样的代码在一个星期后就会变得难以理解。如果你想做一些稍微复杂的事情，例如根据条件简单地在一个列表或集合中添加一个元素，你可能就会犯错误。

单行代码并不是什么成就，是的，他们可能看起来很灵活，但不是什么成就。想象一下，这就像是你在打扫房间时把所有的东西都塞进你的衣橱。好的代码应该是干净的，易于阅读的和高效的。

**利用错误的方式初始化一个集合**

这是一个更微妙的问题，可能让你措手不及。集合推导很像列表推导。

<table style=""> 
 <tbody> 
 <tr> 
 <td> 
 <div style=""> 
 <div> 
 &gt;&gt;&gt; 
 
 { 
 
 n 
 
 for 
 
 n 
 
 in 
 
 range 
 ( 
 10 
 ) 
 
 if 
 
 n 
 
 % 
 
 2 
 
 == 
 
 0 
 
 } 
 </div> 
 <div> 
 { 
 0 
 , 
 
 8 
 , 
 
 2 
 , 
 
 4 
 , 
 
 6 
 } 
 </div> 
 <div> 
 &gt;&gt;&gt; 
 
 type 
 ( 
 { 
 
 n 
 
 for 
 
 n 
 
 in 
 
 range 
 ( 
 10 
 ) 
 
 if 
 
 n 
 
 % 
 
 2 
 
 == 
 
 0 
 
 } 
 ) 
 </div> 
 </div> </td> 
 </tr> 
 </tbody> 
</table>

上面就是集合推导的一个例子。集合就像列表，也是一个容器。所不同的是，一个集合中不能有任何重复的值，而且是无序的。看到集合推导人们经常错误地认为\{\}能初始化一个空集合。但其实不然，它初始化一个空字典。

如果你想初始化一个空集合，可以简单地调用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类。

<table style=""> 
 <tbody> 
 <tr> 
 <td>&nbsp;</td> 
 <td> 
 <div style=""> 
 <div> 
 class 
 
 MyNewObject 
 ( 
 object 
 ) 
 : 
 </div> 
 <div> 
 # stuff here 
 </div> 
 </div> </td> 
 </tr> 
 </tbody> 
</table>

这些“新式”类解决一些老式类的根本缺陷，这一点我们不需要深入了解。然而，如果有人感兴趣，他们可以在相关文档中找到相关信息。

**使用可变的默认参数**

我多次见到过如下的代码：

永远不要使用可变的默认参数，可以使用如下的代码代替：

<table style=""> 
 <tbody> 
 <tr> 
 <td>&nbsp;</td> 
 <td> 
 <div style=""> 
 <div> 
 def 
 
 foo 
 ( 
 a 
 , 
 
 b 
 , 
 
 c 
 = 
 None 
 ) 
 : 
 </div> 
 <div> 
 if 
 
 c 
 
 is 
 
 None 
 : 
 </div> 
 <div> 
 c 
 
 = 
 
 [ 
 ] 
 </div> 
 <div> 
 # append to c 
 </div> 
 <div> 
 # do some more stuff 
 </div> 
 </div> </td> 
 </tr> 
 </tbody> 
</table>

与其解释这个问题是什么，不如展示下使用可变默认参数的影响：

<table style=""> 
 <tbody> 
 <tr> 
 <td>&nbsp;</td> 
 <td> 
 <div style=""> 
 <div> 
 In 
 [ 
 2 
 ] 
 : 
 
 def 
 
 foo 
 ( 
 a 
 , 
 
 b 
 , 
 
 c 
 = 
 [ 
 ] 
 ) 
 : 
 </div> 
 <div> 
 . 
 . 
 . 
 
 c 
 . 
 append 
 ( 
 a 
 ) 
 </div> 
 <div> 
 . 
 . 
 . 
 
 c 
 . 
 append 
 ( 
 b 
 ) 
 </div> 
 <div> 
 . 
 . 
 . 
 
 print 
 ( 
 c 
 ) 
 </div> 
 <div> 
 . 
 . 
 . 
 </div> 
 <div> 
 In 
 [ 
 3 
 ] 
 : 
 
 foo 
 ( 
 1 
 , 
 
 1 
 ) 
 </div> 
 <div> 
 [ 
 1 
 , 
 
 1 
 ] 
 </div> 
 <div> 
 In 
 [ 
 4 
 ] 
 : 
 
 foo 
 ( 
 1 
 , 
 
 1 
 ) 
 </div> 
 <div> 
 [ 
 1 
 , 
 
 1 
 , 
 
 1 
 , 
 
 1 
 ] 
 </div> 
 <div> 
 In 
 [ 
 5 
 ] 
 : 
 
 foo 
 ( 
 1 
 , 
 
 1 
 ) 
 </div> 
 <div> 
 [ 
 1 
 , 
 
 1 
 , 
 
 1 
 , 
 
 1 
 , 
 
 1 
 , 
 
 1 
 ] 
 </div> 
 </div> </td> 
 </tr> 
 </tbody> 
</table>

同一个变量c在函数调用的每一次都被反复引用。这可能有一些意想不到的后果。

**总结**

这些只是相对来说刚接触Python的人可能会遇到的一些问题。然而请注意，可能会遇到的问题远非就这么些。然而另一些缺陷是人们像使用Java或C++一样使用Python，并且试图按他们熟悉的方式使用Python。所以作为本篇文章的一个延续，尝试深入一些东西，例如Python的super函数。看看类方法、静态方法和 \_\_slots\_\_等。

[\[潜在的Python陷阱\]][Python]

[http://blog.csdn.net/pipisorry/article/details/45175457][blog.csdn.net_pipisorry_article_details_45175457]

**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][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 is*optional* by providing a*default value* for it. While this is a greatfeature(特色) of the language, it can lead to someconfusion(混淆) when the default value is*[mutable][]*. 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 expression*each time* the function is called without supplying a value for the optional argument. In the above code, for example, one might expect that calling`foo()` repeatedly (i.e., without  specifying(指定) a `bar` argument) would always return `'baz'`, since the  assumption(假定) would be that*each time*`foo()` 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 an*existing* list each time `foo()` was called, rather than creating a*new* 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, the`bar` argument isinitialized(初始化) to its default (i.e., an empty list) only when`foo()` is first defined, but then calls to`foo()` (i.e., without a`bar` argument specified(规定的)) will continue to use the same list to which`bar` 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 as[Method Resolution Order (MRO)][Method 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 (only`A` in the above example, although Python supports multipleinheritance(继承)). In other words,`C` doesn’t have its own`x` property, independent of `A`. Thus, references(参考) to`C.x` are in fact references to`A.x`. This causes a Python problem unless it’s handled properly. Learn more aout[classattributes(属性) in Python][classattributes_ 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 the*optional* secondparameter(参数)specified(指定) (in this case`e`), in order to make it available for further  inspection(视察). As a result, in the above code, the`IndexError` exception is*not* being caught by the `except`statement(声明); rather, theexception(例外) instead ends up being bound to a parameter named`IndexError`.

The proper way to catch multiple exceptions in an `except` statement is to specify the first parameter as a[tuple][] containing all exceptions to be caught. Also, for maximum portability(可移植性), use the`as` 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 the[LEGB][] rule, which isshorthand(速记法的) for**L**ocal,**E**nclosing, **G**lobal,  **B**uilt-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 this[here][].)

It is particularly common for this to trip up developers when using [ lists][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`, whereas`foo2` is. Remembering that`lst += [5]` is really just shorthand(速记法的) for`lst = lst + [5]`, we see that we are attempting to*assign* a value to`lst` (therefore presumed(假定) by Python to be in the localscope(范围)). However, the value we are looking toassign(分配) to`lst` is based on`lst` 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 of[list 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 of`i` is looked up *in the surrounding scope(范围) at the time it is called* (and by then, theloop(环) has completed, so`i` 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 importing`b.py`, since`b.py` does not require anything from `a.py` to be defined*at the time it is imported*. The onlyreference(参考) in`b.py` to`a` is the call to `a.f()`. But that call is in`g()` and nothing in`a.py` or `b.py` invokes `g()`. So life is good.

But what happens if we attempt to import `b.py` (without having previously imported`a.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 importing`b.py`, it attempts to import`a.py`, which in turn calls `f()`, which attempts to access`b.x`. But `b.x` has not yet beendefined(定义).Hence(因此) the`AttributeError` exception.

At least one solution(解决方案) to this is quitetrivial(不重要的). Simplymodify(修改)`b.py` to import`a.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 named`email.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 a[Python(巨蟒) Enhancement Proposal (PEP)][Python_ 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 the`except` 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 available[here][here 1]).

One way to avoid this issue is to  maintain(维持) a  reference(参考) to theexception(例外) object*outside* thescope(范围) of the`except` 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][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][here 2], when the interpreter(解释者) shuts down, the module’s globalvariables(变量) are all set to`None`. As a result, in the above example, at the point that[`__del__`][del] is invoked(调用), the name`foo` has already been set to`None`.

A solution(解决方案) to this somewhat more advanced Python programming problem would be to use[`atexit.register()`][atexit.register] instead. That way, when your program is finishedexecuting(实行) (when exiting normally, that is), your registered handlers are kicked off*before* 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 to`foo.cleanup` to decide what to do with the object bound to the name`self.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][Python Hiring Guide] for suggestions on interview questions that can helpidentify(确定) Python experts.

from: [http://blog.csdn.net/pipisorry/article/details/45175457][blog.csdn.net_pipisorry_article_details_45175457]

ref:[http://www.toptal.com/python/top-10-mistakes-that-python-programmers-make][http_www.toptal.com_python_top-10-mistakes-that-python-programmers-make]

[blog.csdn.net_pipisorry_article_details_45175457]: http://blog.csdn.net/pipisorry/article/details/45175457
[Python]: http://python.jobbole.com/81564/
[Common Mistakes of Python Programmers]: http://www.onlamp.com/pub/a/python/2004/02/05/learn_python.html
[mutable]: https://docs.python.org/2/reference/datamodel.html
[Method Resolution Order _MRO]: http://python-history.blogspot.com.ar/2010/06/method-resolution-order.html
[classattributes_ in Python]: http://www.toptal.com/python/python-class-attributes-an-overly-thorough-guide
[tuple]: https://docs.python.org/2/tutorial/datastructures.html#tut-tuples
[LEGB]: https://blog.mozilla.org/webdev/2011/01/31/python-scoping-understanding-legb/
[here]: https://docs.python.org/2/faq/programming.html#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value
[lists]: https://docs.python.org/2/tutorial/datastructures.html
[list comprehensions]: https://docs.python.org/2/tutorial/datastructures.html#tut-listcomps
[Python_ Enhancement Proposal _PEP]: http://legacy.python.org/dev/peps/
[here 1]: https://docs.python.org/3/reference/compound_stmts.html#except
[Python Hiring Guide]: http://www.toptal.com/python#hiring-guide
[here 2]: https://mail.python.org/pipermail/python-bugs-list/2009-January/069209.html
[del]: https://docs.python.org/2/reference/datamodel.html#object.__del__
[atexit.register]: https://docs.python.org/2/library/atexit.html
[http_www.toptal.com_python_top-10-mistakes-that-python-programmers-make]: http://www.toptal.com/python/top-10-mistakes-that-python-programmers-make