PEP 8, section by section

Python Indentation and Line Length: 4 Spaces, 79 Characters and Continuation Lines

PEP 8, section by section · By the Four Spaces editorial team · Published 2026-10-27

Indentation is the one part of Python style that is not optional: the interpreter uses it to decide which statements belong to which block. PEP 8 adds conventions on top of that rule, about how much to indent, what to indent with and how long a line may be. This guide explains each one, with the warnings that linters raise when code departs from it.

Four spaces per level

PEP 8's rule is short: "Use 4 spaces per indentation level." Four is a compromise between visibility (two spaces make deep nesting hard to follow) and width (eight spaces push code to the right quickly). It is also what almost every Python project, editor default and formatter uses, which is why it is worth following even in private code: you will read and paste other people's code all the time.

pycodestyle checks the indentation of each logical line. E111 means a line is indented by something that is not a multiple of four; E117 means a block is indented by more than one level at once; E112 and E113 point to an expected or unexpected indent.

Tabs, spaces and why mixing fails

PEP 8 says spaces are the preferred indentation method, and tabs should be used "solely to remain consistent with code that is already indented with tabs". Python 3 enforces the important part: if the meaning of a block would depend on how wide a tab is, the interpreter refuses to run the file.

def total():
    x = 1
	return x   # this line starts with a tab

  File "tab2.py", line 3
    	return x
    ^
TabError: inconsistent use of tabs and spaces in indentation

Linters warn earlier and more broadly. W191 flags any indentation that contains a tab; E101 flags a line whose indentation mixes tabs and spaces. The simplest fix is to configure your editor to insert four spaces when you press Tab, and to convert an existing file once.

Continuation lines

When a statement is too long for one line, PEP 8 describes two ways to indent the continuation:

• Aligned with the opening delimiter, so that the arguments form a visual column.
• A hanging indent, where nothing follows the opening bracket on the first line and the following lines are indented one extra level.

# Aligned with the opening delimiter.
foo = long_function_name(var_one, var_two,
                         var_three, var_four)

# Hanging indent: nothing after "(" on the first line.
foo = long_function_name(
    var_one, var_two,
    var_three, var_four)


# Add an extra level to tell the arguments from the body.
def long_function_name(
        var_one, var_two, var_three,
        var_four):
    print(var_one)

What PEP 8 asks you to avoid is a mix of the two: arguments on the first line followed by lines that are not aligned with them, or a hanging indent at the same level as the body that follows, which makes the parameters look like statements.

For the closing bracket, both of these are accepted: lined up under the first character of the line that started the construct, or under the first non-blank character of the last line of items. Formatters usually pick the first form and put each item on its own line with a trailing comma.

Multi-line if conditions have a known awkwardness: if ( is exactly four characters, so continuation lines line up with the body. PEP 8 deliberately takes no position and lists acceptable options, such as adding a comment or an extra level of indentation on the condition lines.

79 characters, and why

PEP 8 limits code lines to 79 characters and long blocks of text, such as comments and docstrings, to 72. The reasons it gives are practical: a narrow limit lets you keep several files open side by side, works with review tools that show two versions in adjacent columns, and avoids the automatic wrapping that breaks the visual structure of code in editors set to 80 columns.

It also leaves room for teams: "it is okay to increase the line length limit up to 99 characters", provided comments and docstrings stay at 72. The standard library keeps 79. In practice you will meet several numbers: black and ruff default to 88, pylint's default max-line-length is 100, and pycodestyle and flake8 default to 79. Pick one for the project, write it in the configuration, and make sure the linter and the formatter agree. pycodestyle measures length in characters, and reports E501 at the first character beyond the limit.

Wrapping long lines well

The preferred tool is Python's implied line continuation: inside parentheses, brackets and braces, a newline does not end the statement. You can add parentheses around an expression just to get this behaviour.

total = (1
         + 2)

message = ("first part, "
           "second part")
print(total, message)

3 first part, second part

The second example uses another feature worth knowing: adjacent string literals are concatenated by the compiler, so a long message can be split across lines without a +.

Backslash continuation still works but is fragile: a backslash followed by an invisible trailing space is a syntax error. PEP 8 mentions it as acceptable for long with statements in Python versions before 3.10 and for assert statements. Since Python 3.10, several context managers can be grouped in parentheses instead:

with (
    open("input.txt", encoding="utf-8") as source,
    open("output.txt", "w", encoding="utf-8") as target,
):
    target.write(source.read())

Before or after the operator?

For decades the convention was to break a long expression after an operator. PEP 8 now recommends the opposite for new code, citing Donald Knuth's rule for displayed formulas: put the operator at the start of the continuation line, so each operator sits next to its operand.

income = (gross_wages
          + taxable_interest
          + (dividends - qualified_dividends)
          - ira_deduction
          - student_loan_interest)

Both styles remain permitted as long as they are used consistently. That is why pycodestyle's two matching warnings, W503 (line break before binary operator) and W504 (line break after), are both ignored in its default configuration: they contradict each other, and a project enables at most one.

Checking your own code

Paste a snippet into the checker on our home page to see E1xx, W191, E101 and E501 warnings in the browser, with a choice of line limit. It does not check continuation-line alignment (the E12x family), which pycodestyle and flake8 do. For whole projects, see how to run pycodestyle and ruff locally; a formatter such as black will rewrite indentation and line breaks for you, which our guide to whitespace and blank lines also touches on.

Sources

• PEP 8, "Code Lay-out": Indentation, Tabs or Spaces?, Maximum Line Length, Should a Line Break Before or After a Binary Operator?
• Python Language Reference, Lexical analysis: indentation and line structure.
• pycodestyle documentation, error codes E1, E5, W1 and W5; default ignore list. Black documentation, "The Black code style" (line length).

Read next

More in PEP 8, section by section

PEP 8, section by section

Whitespace and blank lines

Spaces around operators and commas, none inside brackets, two blank lines between functions: the rules, the warnings, and the one place the checker disagrees with PEP 8.

PEP 8, section by section

PEP 8, explained section by section

What the official Python style guide actually says, section by section, which parts tools can check, and where it tells you to use your judgment.

Linters & formatters

Black, the code formatter

88 characters, double quotes and the magic trailing comma: what Black changes, the few options it has, and how to make it agree with your linter.