Indentation and blocks

Python differs from most other programming languages because it uses indentation to determine structure (that is, to determine what the while clause of a condition etc. represents). Most other languages use curly braces to do this. In the following example, the indentation of lines 3–6 determines that they belong to the while statement:

1>>> x, y = 6, 3
2>>> while x > y:
3...     x -= 1
4...     if x == 4:
5...         break
6...     print(x)

Indentations to structure the code instead of curly braces takes a little getting used to, but offers significant advantages:

  • You can have neither missing nor too many brackets. Also, you no longer have to search for the bracket that might match earlier brackets.

  • The visual structure of the code reflects its actual structure, making it much easier to understand.

  • Python coding styles are mostly uniform; in other words, your code will mostly look very similar to that of others.


Most of the time, anything that follows # is a comment and is ignored when the code is executed. The obvious exception is # in a string:

>>> x = "# This is a string and not a comment"

Basic Python style

In Python, there are relatively few restrictions on coding style, with the obvious exception that code must be divided into blocks by indentation. Even in this case, how (tabs or spaces) and how far indentation is used is not prescribed. However, there are preferred stylistic conventions for Python, which are contained in the Python Enhancement Proposal (PEP) 8. A selection of Python conventions can be found in the following table:




Module and package names

short, lower case, underscores only if necessary

math, sys

Function names

lower case, underscores if necessary


Variable names

lower case, with underscores if necessary


Class names

CamelCase notation


Constant names

Capital letters with underscores



Four spaces per level, no tabs


not explicitly with True or False, see also Boolean values and expressions

if my_var:, if not my_var:

See also

I strongly recommend following the conventions of PEP 8. They are tried and tested, and make your code easier to understand for yourself and others.