Limit all lines to a maximum of 120 characters.

Long lines can be broken by wrapping expressions in parentheses. Make sure to indent the continued line appropriately. In case of binary operator, break *after* the operator, not before it:

class Rectangle(Blob):

def __init__(self, width, height,
color='black', emphasis=None, highlight=0):
if (width == 0 and height == 0 and
color == 'red' and emphasis == 'strong' or
highlight > 100):
raise ValueError("sorry, you lose")
if width == 0 and height == 0 and (color == 'red' or
emphasis is None):
raise ValueError("I don't think so -- values are %s, %s" %
(width, height))
Blob.__init__(self, width, height,
color, emphasis, highlight)

Encodings

Use the UTF-8.

Imports

Relative imports for intra-package imports are discouraged.
Use the absolute package path for all imports.

When importing a class from a class-containing module, spell this:
from myclass import MyClass
from foo.bar.yourclass import YourClass
Use qualified import when needed
import myclass
import foo.bar.yourclass
and use myclass.MyClass and foo.bar.yourclass.YourClass.

White-space in Expressions and Statements

Avoid extra white-space in the following situations:

Immediately inside parentheses, brackets or braces.
Yes: spam(ham[1], {eggs: 2})
No: spam( ham[ 1 ], { eggs: 2 } )
Immediately before a comma, semicolon, or colon:
Yes: if x == 4:

print x, y; x, y = y, x

No: if x == 4 :

print x , y ; x , y = y , x

Immediately before the open parenthesis that starts the argument list of a function call:
Yes: spam(1)
No: spam (1)
Immediately before the open parenthesis that starts an indexing or slicing:
Yes: dict['key'] = list[index]
No: dict ['key'] = list [index]

Compound statements (multiple statements on the same line) are generally discouraged.
Yes:
if foo == 'blah':
do_blah_thing()
do_one()
do_two()
do_three()

Rather not:
if foo == 'blah': do_blah_thing()
do_one(); do_two(); do_three()
While sometimes it's okay to put an if/for/while with a small body on the same line, never do this for multi-clause statements. Also avoid folding such long lines!
Rather not:
if foo == 'blah': do_blah_thing()
for x in lst: total += x
while t < 10: t = delay()

Definitely not:
if foo == 'blah': do_blah_thing()
else: do_non_blah_thing()

try: something()
finally: cleanup()

do_one(); do_two(); do_three(long, argument,
list, like, this)

if foo == 'blah': one(); two(); three()

Other recommendations::

Surround these binary operators with a single space on either side: assignment (=), augmented assignment (+=, -= etc.), comparisons (==, <, >, !=, <>, <=, >=, in, not in, is, is not), Booleans (and, or, not).
Use spaces around arithmetic operators:
Yes:
i = i + 1
submitted += 1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)

No:
i=i+1
submitted +=1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)
Use spaces around the '=' sign when used to indicate a keyword argument or a default parameter value.

Yes:
def complex(real, imag = 0.0):
return magic(r = real, i = imag)

No:
def complex(real, imag=0.0):
return magic(r=real, i=imag)

Documentation Strings

Write docstrings for modules, functions, classes, and methods.

The comment should appear after the "def" line.

Naming Conventions

Names to Avoid

Never use the characters `l' (lowercase letter el), `O' (uppercase letter oh), or `I' (uppercase letter eye) as single character variable names (they are indistinguishable from the numerals one and zero).

Package and Module Names

Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged:

import copy

from operator import itemgetter

Class Names

Class names use the CapitalizedWords convention. Classes for internal use have a leading underscore in addition:

class LineOverlayObject(BaseOverlayObject):

class _PrivateOverlayObject(BaseOverlayObject):

Exception Names

Exceptions are classes, so the class naming convention applies here. However, use the suffix "Error" on your exception names (if the exception actually is an error).

class CustomError(Exception):

Global Variable Names

The conventions are the same as for functions.
Modules that are designed for use via "from M import *" should use the __all__ mechanism to prevent exporting globals, or use the older convention of prefixing such globals with an underscore (which you might want to do to indicate these globals are "module non-public").

Function Names

Use mixedCase for function definitions:

def updateLineEnds(self):

Function and method arguments

Always use 'self' for the first argument to instance methods.

Always use 'cls' for the first argument to class methods.

If a function argument's name clashes with a reserved keyword, it is generally better to append a single trailing underscore rather than use an abbreviation or spelling corruption. Thus "class_" is better than "cls" (Exception for class methods). (The best is to avoid such clashes by using a synonym.)

Method Names and Instance Variables

Use one leading underscore only for non-public methods and instance variables.

To avoid name clashes with subclasses, use two leading underscores to invoke Python's name mangling rules:

def __innerUpdateLineEnds(self):

Python mangles these names with the class name: if class Foo has an attribute named __a, it cannot be accessed by Foo.__a. (An insistent user could still gain access by calling Foo._Foo__a.) Double leading underscores are used only to avoid name conflicts with attributes in classes designed to be subclassed.

Constants

Constants are defined on a module level and written in all capital letters with underscores:

MAX_OVERFLOW.

Designing for inheritance

Public attributes have no leading underscores.

For simple public data attributes, expose just the attribute name, without complicated accessor/mutator methods. In that case, use properties to hide functional implementation behind simple data attribute access syntax.

Try to keep the functional behavior side-effect free, although side-effects such as caching are generally fine.

Avoid using properties for computationally expensive operations; the attribute notation makes the caller believe that access is (relatively) cheap.

If your class is intended to be subclassed, and you have attributes that you do not want subclasses to use, consider naming them with double leading underscores and no trailing underscores. This invokes Python's name mangling algorithm, where the name of the class is mangled into the attribute name. This helps avoid attribute name collisions should subclasses inadvertently contain attributes with the same name.

Programming Recommendations

Don’t use "if x" when you really mean "if x is not None" - e.g. when testing whether a variable or argument that defaults to None was set to some other value. The other value might have a type (such as a container) that could be false in a boolean context!

define their own domain-specific base exception class for modules and packages, which should be subclassed from the built-in Exception class. Always include a class docstring:

class MessageError(Exception):

"""Base class for errors in the email package."""

When raising an exception, use "raise ValueError('message')" instead of the older form "raise ValueError, 'message'".

When catching exceptions, mention specific exceptions whenever possible instead of using a bare 'except:' clause. For example, use:

try:

import platform_specific_module

except ImportError:

platform_specific_module = None

If you want to catch all exceptions that signal program errors, use 'except Exception:'.

Use of bare 'except' clauses in two cases:

if the exception handler will be printing out or logging the traceback; at least the user will be aware that an error has occurred;
if the code needs to do some cleanup work, but then lets the exception propagate upwards with 'raise'. 'try...finally' is a better way to handle this case.

Additionally, for all try/except clauses, limit the 'try' clause to the absolute minimum amount of code necessary (this avoids masking bugs).

Yes:

try:

value = collection[key]

except KeyError:

return key_not_found(key)

else:

return handle_value(value)

No:

try:

# Too broad!

return handle_value(collection[key])

except KeyError:

# Will also catch KeyError raised by handle_value()

return key_not_found(key)

Use string methods instead of the string module.

Use ''.startswith() and ''.endswith() instead of string slicing to check for prefixes or suffixes. startswith() and endswith() are cleaner and less error prone::

Yes: if foo.startswith('bar'):

No: if foo[:3] == 'bar':

Object type comparisons should always use isinstance() instead of comparing types directly.

Yes: if isinstance(obj, int):

No: if type(obj) is type(1):

For sequences, (strings, lists, tuples), use the fact that empty sequences are false.

Yes: if not seq:

if seq:

No: if len(seq)

if not len(seq)