This document gives coding conventions for the Python code comprising the
standard library in the main Python distribution. Please see the
companion informational PEP describing style guidelines for the C code in
the C implementation of Python.
This document was adapted from Guido’s original Python Style Guide
essay, with some additions from Barry’s style guide. Where there’s
conflict, Guido’s style rules for the purposes of this PEP. This PEP may
still be incomplete (in fact, it may never be finished ).
A Foolish Consistency is the Hobgoblin of Little Minds
One of Guido’s key insights is that code is read much more often than it
is written. The guidelines provided here are intended to improve the
readability of code and make it consistent across the wide spectrum of
Python code. As PEP 20  says, “Readability counts”.
A style guide is about consistency. Consistency with this style guide is
important. Consistency within a project is more important. Consistency
within one module or function is most important.
But most importantly: know when to be inconsistent – sometimes the style
guide just doesn’t apply. When in doubt, use your best judgment. Look
at other examples and decide what looks best. And don’t hesitate to ask!
Two good reasons to break a particular rule:
(1) When applying the rule would make the code less readable, even for
someone who is used to reading code that follows the rules.
(2) To be consistent with surrounding code that also breaks it (maybe for
historic reasons) – although this is also an opportunity to clean up
someone else’s mess (in true XP style).
Use 4 spaces per indentation level.
For really old code that you don’t want to mess up,
you can continue to
use 8-space tabs.
Tabs or Spaces?
Never mix tabs and spaces.
The most popular way of indenting Python is with spaces only. The
second-most popular way is with tabs only. Code indented with a mixture
of tabs and spaces should be converted to using spaces exclusively. When
invoking the Python command line interpreter with the – t option, it issues
warnings about code that illegally mixes tabs and spaces. When using – tt
these warnings become errors. These options are highly recommended!
For new projects, spaces-only are strongly recommended over tabs. Most
editors have features that make this easy to do.
Maximum Line Length
Limit all lines to a maximum of 79 characters.
There are still many devices around that are limited to 80 character
lines; plus, limiting windows to 80 characters makes it possible to have
several windows side-by-side. The default wrapping on such devices
disrupts the visual structure of the code, making it more difficult to
understand. Therefore, please limit all lines to a maximum of 79
characters. For flowing long blocks of text (docstrings or comments),
limiting the length to 72 characters is recommended.
The preferred way of wrapping long lines is by using Python’s implied line
continuation inside parentheses, brackets and braces. If necessary, you
can add an extra pair of parentheses around an expression, but sometimes
using a backslash looks better. Make sure to indent the continued line
appropriately. The preferred place to break around a binary operator is
*after* the operator, not before it. Some examples: