What Is PEP 8 and Why Follow It?

The original code breaks three rules of PEP 8. The function name uses capitals in the middle instead of small words joined with underscores. The arguments are all packed onto one line, which makes the line longer than the guide recommends. And the body uses a mix of spaces and tabs for its indentation.

# Before: name style, over-long line, tab indentation
def CalculateTotal(price,quantity,taxRate=0.2):
    return price*quantity + (price*quantity*taxRate)

# After: small words with underscores, one argument per line, four spaces
def calculate_total(price, quantity, tax_rate=0.2):
    subtotal = price * quantity
    return subtotal + (subtotal * tax_rate)


print(calculate_total(20, 3))

The output is 72.0, which is 60 plus a tax of 20 percent, and that tax is 12.

PEP 8 has opinions about other things too, and the corrected version follows them. Function names and variable names use small words joined with underscores. Class names use capitals in the middle. In a def line, an argument has spaces around its equals sign, and a default value has no spaces around its own equals sign. Lines are recommended to stay at 79 characters or fewer, and many projects allow a relaxed limit of 99. Two blank lines separate a definition at the top level of a file, and one blank line separates the methods inside a class.

The bigger point to make in an interview is that PEP 8 is a style guide, and not a rule of the syntax. The interpreter does not check one of those conventions. It only cares that your code can be read as a program. What makes the guide valuable is that everyone makes the same arbitrary choices, and that makes code review faster for every project in the world.

PEP 8 is the Python Style Guide. It is the document that describes the conventions that every Python programmer is expected to follow, such as how to name things, how to lay out a function, how wide the lines should be, when to use blank lines, and how to write comments and docstrings. Guido van Rossum and Tim Peters wrote it in 2001, and it has been revised several times since. The biggest revision came in 2020, when the guide was reformatted and expanded.

Nobody enforces it at the level of the language. The interpreter accepts almost any style, as long as the code parses. In practice it is the tools that enforce it. The programs flake8, pylint, pycodestyle, and ruff all ship with rules that come from PEP 8, and most projects connect one of them to their continuous integration system, so that a style mistake fails the build.

The decision is therefore made per project, and it is usually made by the team rather than by the language. A project with a large existing code base may write down its own exceptions in a configuration file, because reformatting everything usually costs more than it saves. A new project normally takes the defaults and lets a formatter settle the arguments automatically.

Two points are worth raising in an interview. PEP 8 says nothing about naming things that are not Python identifiers, such as API routes or database columns. And some of its advice is deliberately advisory, written as a should rather than a must, which is why the community has been comfortable with Black and Ruff producing slightly different results in the few places that are still open.