- 浏览: 509496 次
文章分类
最新评论
Top 10 Mistakes that Python Programmers Make
About Python
Pythonis an interpreted, object-oriented, high-level programming language with dynamic semantics. Its high-level built in data structures, combined with dynamic typing and dynamic binding, make it very attractive forRapid Application Development, as well as for use as a scripting or glue language to connect existing components or services. Python supports modules and packages, thereby encouraging program modularity and code reuse.
About this article
Python’s simple, easy-to-learn syntax can mislead Python developers – especially those who are newer to the language – into missing some of its subtleties and underestimating the power of the language.
With that in mind, this article presents a “top 10” list of somewhat subtle, harder-to-catch mistakes that can bite even the most advanced Python developer in the rear.
(Note: This article is intended for a more advanced audience thanCommon 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 isoptionalby providing adefault valuefor it. While this is a great feature of the language, it can lead to some confusion when the default value ismutable. For example, consider this Python function definition:
>>> 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
timethe 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 abar
argument)
would always return'baz'
,
since the assumption would be thateach timefoo()
is
called (without abar
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
anexistinglist each timefoo()
was
called, rather than creating anewlist each time?
The answer is thatthe default value for a function argument is only evaluated
once, at the time that the function is defined.Thus, thebar
argument
is initialized 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 class variables 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 changedA.x
.
Why didC.x
change
too?
In Python, class variables are internally handled as dictionaries and follow what is often referred to asMethod
Resolution Order (MRO). So in the above code, since the attributex
is
not found in classC
,
it will be looked up in its base classes (onlyA
in
the above example, although Python supports multiple inheritance). In other words,C
doesn’t
have its ownx
property,
independent ofA
.
Thus, references toC.x
are
in fact references toA.x
.
Common Mistake #3: Specifying parameters incorrectly for an exception 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 theexcept
statement
doesnottake a list of exceptions specified in this manner. Rather,
In Python 2.x, the syntaxexcept
Exception, e
is used to bind the exception to theoptionalsecond
parameter specified (in this casee
),
in order to make it available for further inspection. As a result, in the above code, theIndexError
exception
isnotbeing caught by theexcept
statement;
rather, the exception instead ends up being bound to a parameter namedIndexError
.
The proper way to catch multiple exceptions in anexcept
statement
is to specify the first parameter as atuplecontaining
all exceptions to be caught. Also, for maximum portability, use theas
keyword,
since that syntax 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 Python scope rules
Python scope resolution is based on what is known as theLEGBrule, which is shorthand forLocal,Enclosing,Global,Built-in. Seems straightforward enough, right? Well, actually, there are some subtleties to the way this works in Python. 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 anassignmentto a variable in a scope,that variable is automatically considered by Python to be local to that scopeand shadows any similarly named variable in any outer scope.
Many are thereby surprised to get anUnboundLocalError
in
previously working code when it is modified by adding an assignment 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 usinglists. 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 didfoo2
bomb
whilefoo1
ran
fine?
The answer is the same as in the prior example, but is admittedly more subtle.foo1
is
not making anassignmenttolst
,
whereasfoo2
is.
Remembering thatlst
+= [5]
is really just shorthand forlst
= lst + [5]
, we see that we are attempting toassigna value
tolst
(therefore
presumed by Python to be in the local scope). However, the value we are looking to assign tolst
is
based onlst
itself
(again, now presumed to be in the local scope), which has not yet been defined. Boom.
Common Mistake #5: Modifying a list while iterating 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 faux pas 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 more complex.
Fortunately, Python incorporates a number of elegant programming paradigms which, when used properly, can result in significantly simplified and streamlined code. A side benefit 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 this specific problem, as shown by this alternate 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 Python binds variables in closures
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’slate bindingbehavior which says that the
values of variables used in closures 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 upin the surrounding scope at the time it is called(and by
then, the loop has completed, soi
has
already been assigned its final value of 4).
The solution to this 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 this elegant. Some would call it subtle. Some hate it. But if you’re a Python developer, it’s important to understand in any case.
Common Mistake #7: Creating circular module dependencies
Let’s say you have two files,a.py
andb.py
,
each of which imports the other, as follows:
Ina.py
:
import b
def f():
return b.x
print f()
And inb.py
:
import a
x = 1
def g():
print a.f()
First, let’s try importinga.py
:
>>> import a
1
Worked just fine. Perhaps that surprises you. After all, we do have a circular import here which presumably should be a problem, shouldn’t it?
The answer is that the merepresenceof 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 or variables defined in the other, you may indeed run into problems.
So returning to our example, when we importeda.py
,
it had no problem importingb.py
,
sinceb.py
does
not require anything froma.py
to
be definedat the time it is imported. The only reference inb.py
toa
is
the call toa.f()
.
But that call is ing()
and
nothing ina.py
orb.py
invokesg()
.
So life is good.
But what happens if we attempt to importb.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 callsf()
,
which attempts to accessb.x
.
Butb.x
has
not yet been defined. Hence theAttributeError
exception.
At least one solution to this is quite trivial. Simply modifyb.py
to
importa.py
withing()
:
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: Name clashing 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 not consciously 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 stuff happens.
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 change upstream and to try and get that approved.
Common Mistake #9: Failing to address differences between Python 2 and Python 3
Consider the following filefoo.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 not accessible beyond the scope of theexcept
block.
(The reason for this is that, otherwise, it would keep a reference cycle with the stack frame in memory until the garbage collector runs and purges the references from memory. More technical detail about this is availablehere).
One way to avoid this issue is to maintain a reference to the exception objectoutsidethe
scope of theexcept
block
so that it remains accessible. Here’s a version of the previous example that uses this technique, thereby yielding 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, ourPython Hiring Guidediscusses a number of other important differences to be aware of when migrating code from Python 2 to Python 3.)
Common Mistake #10: Misusing the__del__
method
Let’s say you had this in a file calledmod.py
:
import foo
class Bar(object):
...
def __del__(self):
foo.cleanup(self.myhandle)
And you then tried to do this fromanother_mod.py
:
import mod
mybar = mod.Bar()
You’d get an uglyAttributeError
exception.
Why? Because, as reportedhere,
when the interpreter shuts down, the module’s global variables 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 would be to useatexit.register()
instead.
That way, when your program is finished executing (when exiting normally, that is), your registered handlers are kicked offbeforethe
interpreter is shut down.
With that understanding, a fix for the abovemod.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 and reliable way of calling any needed cleanup functionality upon normal program termination. 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 and flexible language with many mechanisms and paradigms that can greatly improve productivity. As with any software tool or language, though, having a limited understanding or appreciation of its capabilities can sometimes be more of an impediment than a benefit, leaving one in the proverbial state of “knowing enough to be dangerous”.
Familiarizing oneself with the key nuances of Python, such as (but by no means limited to) the issues raised in this article, will help optimize use of the language while avoiding some of its more common pitfalls.
You might also want to check out ourInsider’s Guide to Python Interviewingfor suggestions on interview questions that can help identify Python experts.
We hope you’ve found the pointers in this article helpful and welcome your feedback.
中文翻译版:http://www.csdn.net/article/2014-05-12/2819716-Top-10-Mistakes-that-Python-Programmers-Make
相关推荐
How to make mistakes in python
How to make mistakes in Python
How-to-Make-Mistakes-in-Python.pdf
Several other major mistakes all Python programmers need to know about (as well as how to avoid them) A critical mistake every new Python programmer rushes into and needs to slow down a little bit ...
The 10 Biggest Mistakes Developers Make with QUALCOMM BREW By Ray Rischpater
SQL Server Database 数据库 使用中最容易犯的10个错误
藏经阁-Top 5 mistakes when wriiting a.pdf
Top 10 Most Common Mistakes on Microsoft SQL Server
Written for developers and experienced programmers, Serious Python brings together over 15 years of Python experience to teach you how to avoid common mistakes, write code more efficiently, and build...
E-Book_The 10 biggest mistakes companies make inChina-Mar-0_4-
Python Crash Course is a fast-paced, thorough introduction to programming with Python that will have you writing programs, solving problems, and making things that work in no time. In the first half ...
Python Crash Course is a fast-paced, thorough introduction to programming with Python that will have you writing programs, solving problems, and making things that work in no time. In the first half ...
Written for developers and experienced programmers, Serious Python brings together over 15 years of Python experience to teach you how to avoid common mistakes, write code more efficiently, and build...
You'll discover how to spot crucial differences that fundamentally affect program behavior, and you'll learn everything you need to know about Python logic, input/output, variables, and functions....
Training non-Python Programmers 397 Python Employment Resources 397 Python Problems 397 Porting to Other Versions of Python 397 Porting to Other Operating Systems 398 Debugging Threads 399 ...
Drupal has its own set of programming principles that require a different approach, and many programmers make mistakes when relying on skills they’ve used for other projects. The guidelines in this ...
笨方法学Python号称最经典的python入门书籍现在出python3版本的了,你还不快来学? 英文高清带书签版本 You Will Learn Python 3! Zed Shaw has perfected the world’s best system for learning Python 3. ...
You'll discover how to spot crucial differences that fundamentally affect program behavior, and you'll learn everything you need to know about Python logic, input/output, variables, and functions....
不知道为啥移动的网络死活在官网下不了。。。 NekoHTML is a simple HTML scanner and tag balancer that enables application programmers to parse ...authors make in writing ...
Author Andrey Akinshin has maintained BenchmarkDotNet (the most popular .NET library for benchmarking) for five years and covers common mistakes that developers usually make in their benchmarks....