Why Does Indentation Matter in Python?

Indentation is not decoration in Python. It is the block syntax. The parser uses the spaces at the start of a line to decide which statements belong to the same body, so two programs that contain exactly the same words can behave differently because of nothing but the whitespace.

def collect(flag):
    result = []
    if flag:
        result.append('a')
        result.append('b')
    result.append('c')
    return result


print(collect(True))    # ['a', 'b', 'c']
print(collect(False))   # ['c']

Both of the append calls sit inside the body of the if, because they are indented one level deeper than the if itself. The last append is at the same level as the if, so it always runs. Move it out by four spaces and the meaning of the block changes completely.

Indentation also decides the scope, and that is why a name that you create inside a block disappears when the block ends.

def scope_demo():
    inner = 'visible here'
    if True:
        deeper = 'also visible here'
    return inner


print(scope_demo())
print(deeper)   # NameError: name 'deeper' is not defined

Every function, loop, conditional, with block, and try block creates its own local scope. Names that you bind inside it are visible only inside it, and they are gone once the block finishes.

The practical result for code review is that indentation carries real meaning. One stray space can change what a program does without giving you an error, and that is exactly why mixing tabs and spaces is dangerous. The same file can look identical in two editors and still be read in two different ways.

PEP 8 recommends four spaces for each level of indentation, and that is the rule that almost everybody follows. Eight spaces are allowed in rare cases where a clear visual divide helps the reader, such as a deeply nested continuation line, but four is the default that people expect. The limit of 79 characters per line is the other half of the same advice, because four spaces multiplied by a nesting depth of four already uses up a quarter of the space on the line.

Mixing tabs and spaces is forbidden by the style guide for a concrete reason. The width of a tab is a decision made by the program that shows you the file, and it is not a fixed number of columns. An editor set to eight columns and an editor set to four columns will display the same file differently. Because Python moves to the next multiple of eight when it reads a tab, the parser can see two different levels of indentation where the author saw one. The result is code that looks right on the author's screen and fails on everybody else's, often with an IndentationError that points at a line that nobody touched.

Python 3 turns this from a style rule into a hard rule. The interpreter refuses to mix tabs and spaces in the same source file, and it raises a TabError instead of guessing what you meant. Python 2 allowed it, and that is why older projects still contain files like that.

The practical advice an interviewer wants to hear is this. Set your editor to insert spaces instead of tabs, keep the tab width at four, and let the editor manage the indentation instead of typing it by hand. Modern editors and formatters such as Black do all of this for you automatically.