Language Constructs You Should Not Use

While Python has relatively few gotchas compared to other languages, it still has some constructs which are only useful in corner cases, or are plain dangerous.

f = open("www")
f.read()

>>> for name in sys.argv[1:]:
>>>     exec "%s=1" % name
>>> def func(s, **kw):
>>>     for var, val in kw.items():
>>>         exec "s.%s=val" % var  # invalid!
>>> execfile("handler.py")
>>> handle()

>>> d = {}
>>> for name in sys.argv[1:]:
>>>     d[name] = 1
>>> def func(s, **kw):
>>>     for var, val in kw.items():
>>>         setattr(s, var, val)
>>> d={}
>>> execfile("handle.py", d, d)
>>> handle = d['handle']
>>> handle()

# foo.py
a = 1

# bar.py
from foo import a
if something():
    a = 2 # danger: foo.a != a

# foo.py
a = 1

# bar.py
import foo
if something():
    foo.a = 2

try:
    foo = opne("file") # misspelled "open"
except:
    sys.exit("could not open file!")

try:
    foo = opne("file")
except IOError:
    sys.exit("could not open file")

Exceptions

Exceptions are a useful feature of Python. You should learn to raise them whenever something unexpected occurs, and catch them only where you can do something about them.

The following is a very popular anti-idiom

def get_status(file):
    if not os.path.exists(file):
        print "file not found"
        sys.exit(1)
    return open(file).readline()

Consider the case where the file gets deleted between the time the call to os.path.exists() is made and the time open() is called. In that case the last line will raise an IOError. The same thing would happen if file exists but has no read permission. Since testing this on a normal machine on existent and non-existent files makes it seem bugless, the test results will seem fine, and the code will get shipped. Later an unhandled IOError (or perhaps some other EnvironmentError) escapes to the user, who gets to watch the ugly traceback.

Here is a somewhat better way to do it.

def get_status(file):
    try:
        return open(file).readline()
    except EnvironmentError as err:
        print "Unable to open file: {}".format(err)
        sys.exit(1)

In this version, either the file gets opened and the line is read (so it works even on flaky NFS or SMB connections), or an error message is printed that provides all the available information on why the open failed, and the application is aborted.

However, even this version of get_status() makes too many assumptions — that it will only be used in a short running script, and not, say, in a long running server. Sure, the caller could do something like

try:
    status = get_status(log)
except SystemExit:
    status = None

But there is a better way. You should try to use as few except clauses in your code as you can — the ones you do use will usually be inside calls which should always succeed, or a catch-all in a main function.

So, an even better version of get_status() is probably

def get_status(file):
    return open(file).readline()

The caller can deal with the exception if it wants (for example, if it tries several files in a loop), or just let the exception filter upwards to its caller.

But the last version still has a serious problem — due to implementation details in CPython, the file would not be closed when an exception is raised until the exception handler finishes; and, worse, in other implementations (e.g., Jython) it might not be closed at all regardless of whether or not an exception is raised.

The best version of this function uses the open() call as a context manager, which will ensure that the file gets closed as soon as the function returns:

def get_status(file):
    with open(file) as fp:
        return fp.readline()

Using the Batteries

Every so often, people seem to be writing stuff in the Python library again, usually poorly. While the occasional module has a poor interface, it is usually much better to use the rich standard library and data types that come with Python than inventing your own.

A useful module very few people know about is os.path. It always has the correct path arithmetic for your operating system, and will usually be much better than whatever you come up with yourself.

Compare:

# ugh!
return dir+"/"+file
# better
return os.path.join(dir, file)

More useful functions in os.path: basename(), dirname() and splitext().

There are also many useful built-in functions people seem not to be aware of for some reason: min() and max() can find the minimum/maximum of any sequence with comparable semantics, for example, yet many people write their own max()/min(). Another highly useful function is reduce() which can be used to repeatly apply a binary operation to a sequence, reducing it to a single value. For example, compute a factorial with a series of multiply operations:

>>> n = 4
>>> import operator
>>> reduce(operator.mul, range(1, n+1))
24

When it comes to parsing numbers, note that float(), int() and long() all accept string arguments and will reject ill-formed strings by raising an ValueError.

Using Backslash to Continue Statements

Since Python treats a newline as a statement terminator, and since statements are often more than is comfortable to put in one line, many people do:

if foo.bar()['first'][0] == baz.quux(1, 2)[5:9] and \
   calculate_number(10, 20) != forbulate(500, 360):
      pass

You should realize that this is dangerous: a stray space after the \ would make this line wrong, and stray spaces are notoriously hard to see in editors. In this case, at least it would be a syntax error, but if the code was:

value = foo.bar()['first'][0]*baz.quux(1, 2)[5:9] \
        + calculate_number(10, 20)*forbulate(500, 360)

then it would just be subtly wrong.

It is usually much better to use the implicit continuation inside parenthesis:

This version is bulletproof:

value = (foo.bar()['first'][0]*baz.quux(1, 2)[5:9]
        + calculate_number(10, 20)*forbulate(500, 360))