Python Syntax

From characters to statements

Python does not treat a source file as a bag of English-like sentences. Before the parser can decide whether a program follows the grammar, lexical analysis reads decoded source characters and produces tokens. Common token categories include names, literals, operators, delimiters, and special structural markers such as NEWLINE, INDENT, and DEDENT. You do not need to inspect tokens for ordinary programming, but the model explains why apparently small edits can change a program's structure. For example, total=3 and total = 3 have the same essential tokens; spacing is not needed around the equals sign in that case. By contrast, blue sky contains two name tokens, whereas bluesky is one name token. Whitespace is required when omitting it would make adjacent characters a different token.

A physical line is a sequence of characters ending in a line ending. A logical line is what the language uses for a statement boundary. One logical line may occupy more than one physical line when a continuation rule applies. This distinction is useful because a source file can be formatted over several screen lines without necessarily becoming several statements. A simple statement is contained in one logical line. Several simple statements can technically share a logical line when separated by semicolons, but one statement per line is usually easier to scan and edit.

An expression is source text that Python evaluates to obtain a value; it can appear as part of a larger statement. A statement is a complete instruction in the grammar. This lesson does not attempt to catalog expression forms or statements such as assignment, import, or return. The useful syntax-level distinction is that expressions are ingredients, while statements establish the program's top-level actions and structure.

Whitespace, comments, and continued lines

Most spaces, tabs, and formfeeds between tokens are interchangeable delimiters. At the beginning of a logical line, however, leading spaces and tabs have another job: Python uses their indentation level to determine how statements are grouped. This is the famous meaningful whitespace rule. It is not a style convention layered on top of braces; indentation is part of the language's structure.

A comment starts with # when that character is outside a string literal and continues through the physical line's end. The parser ignores the comment's text. Comments are for a reader: explain a non-obvious decision, constraint, or consequence rather than narrating a line that already reads clearly. A hash inside a quoted string is ordinary string content, not a comment starter.

There are two ways to continue a logical line. Explicit joining uses a backslash at the end of a physical line. The backslash joins that line to the next one, but it is fragile: it cannot be followed by a comment, and an accidental trailing character defeats the continuation. Implicit joining is usually clearer. An expression inside parentheses, square brackets, or curly braces may span physical lines without a backslash, and those continuation lines may contain comments. Format the pieces vertically so a reader can see what belongs together.

For example, this valid expression uses parentheses for continuation:

message = (
    "syntax gives code structure"
    " before it runs"
)
print(message)

Adjacent string literals inside parentheses are concatenated by the language, so the output is syntax gives code structure before it runs. The point here is formatting and grouping, not string techniques: the parentheses permit line breaks while preserving one logical line.

Suites: indentation that groups work

Some statements are compound statements. A compound statement is made of one or more clauses. Each clause has a header and a suite: the header begins with a keyword, ends in a colon, and its suite is the group of statements that the clause controls. Although a suite can be written as simple statements on the same line as a header, the normal multi-line form is the one that supports nested compound statements and is much more readable.

A deliberately minimal example shows only the shape:

if ready:
    print("begin")
print("outside the suite")

The indented print is in the if header's suite. The final print returns to the surrounding indentation level, so it is outside that suite. This lesson is about that structural boundary, not about how conditions work. A suite must have at least one statement; when a structure is intentionally empty during drafting, Python provides the pass statement as a syntactic placeholder.

The tokenizer compares leading indentation levels across logical lines and emits INDENT and DEDENT markers to represent changes. A line indented farther than the current level begins an indented block; returning to an earlier level closes one or more blocks. Use one consistent indentation convention in a file—four spaces is a widespread convention—and configure your editor to display whitespace when an indentation problem is hard to see. The language specifically rejects mixes of tabs and spaces when their meaning depends on tab width, raising TabError. Even a visually aligned mixture can therefore be a poor choice.

What syntax-related errors mean

A SyntaxError means Python could not parse the source as valid Python grammar. It can arise from many forms of invalid source: a missing colon after a compound-statement header, an unclosed delimiter, a misplaced keyword, or source that cannot be decoded. The caret and location in the message are clues, not always a proof that the indicated character is the original mistake; an earlier unclosed construct can make a later location look surprising.

IndentationError is the exception family associated with indentation problems. A common instance reports an unexpected indent when an indentation increase does not follow a construct that starts a suite. Another reports an expected indented block after a colon-ended header when the required suite is absent. TabError is a more specific indentation-related error for a problematic mixture of tabs and spaces. These errors occur while Python is processing source structure, not because a later computation produced an unwanted result.

When you read one, first compare the line with the surrounding structural pattern: does a header end in a colon; does its following suite align consistently; did a closing parenthesis or bracket go missing above? This is source reading, not a full debugging workflow. Fix the program's structure, then let Python parse it again. Keeping code short, using one statement per line, and preferring implicit continuation reduce opportunities for structural ambiguity.