PEP 8 & Style Interview Questions & Answers

PEP 8 is the official style guide for Python code — a set of conventions for formatting and naming that make code consistent and readable across the community. It's a recommendation, not a language rule: code that violates PEP 8 still runs fine, but consistency aids collaboration.

# PEP 8 style
def calculate_total(items, tax_rate=0.0):
    subtotal = sum(items)
    return subtotal * (1 + tax_rate)

# not PEP 8 — cramped, inconsistent spacing/naming
def calcTotal(items,taxRate=0.0):
    subTotal=sum(items);return subTotal*(1+taxRate)

PEP 8 covers indentation (4 spaces), naming, whitespace, imports, and line length. Its guiding principle: readability counts, since code is read far more often than it's written.

PEP 8 assigns a distinct case to each kind of name so readers can tell them apart at a glance. snake_case for functions, variables, and modules; PascalCase (CapWords) for classes; UPPER_SNAKE_CASE for constants. A single leading underscore signals "internal".

MAX_RETRIES = 3                  # constant — UPPER_SNAKE_CASE

class HttpClient:                # class — PascalCase
    def send_request(self):      # method — snake_case
        retry_count = 0          # variable — snake_case
        self._session = None     # _leading underscore = "internal"

Avoid single-character names like l, O, I (they look like digits). Method/ function names use the same snake_case as variables; only classes and exceptions use PascalCase.

Imports go at the top of the file, one per line, grouped in order: standard library, third-party, then local — separated by blank lines. For line length, PEP 8 recommends a maximum of 79 characters (72 for docstrings/ comments), though many modern teams relax this to 88 or 100.

# standard library
import os
import sys

# third-party
import requests

# local
from myapp.utils import helper

# avoid: import os, sys   (multiple on one line)

Keeping imports sorted and grouped makes dependencies obvious. The line-length cap keeps code readable in side-by-side diffs and narrow editors; tools like isort automate import ordering.

The Zen of Python (PEP 20) is a collection of 19 guiding aphorisms that capture Python's design philosophy. You can read it any time by running import this. It informs why the language and its idioms look the way they do.

import this
# Beautiful is better than ugly.
# Explicit is better than implicit.
# Simple is better than complex.
# Readability counts.
# There should be one-- and preferably only one --obvious way to do it.
# ...and 14 more

The aphorisms favor clarity, simplicity, and explicitness over cleverness. They aren't enforced rules but a cultural compass — when two approaches compete, the Zen usually points to the more Pythonic one.

A formatter automatically rewrites your code into a consistent layout; a linter analyzes code and reports style violations and likely bugs without (usually) changing it. black is the dominant formatter (opinionated, near-zero-config); ruff is an extremely fast linter (and formatter) that consolidates many older tools.

# before black
x = {'a':1,'b':2}
# after black
x = {"a": 1, "b": 2}

# command line
# black .          -> reformats files in place
# ruff check .     -> reports lint issues
# ruff check --fix -> auto-fixes what it can

Running a formatter ends style arguments in code review (the tool decides), while a linter catches unused imports, undefined names, and anti-patterns. Most teams run both, often automatically via pre-commit hooks or CI.

PEP 8 itself says "A Foolish Consistency is the Hobgoblin of Little Minds" — style serves readability, so break the rules when following them would make code less readable or when you must stay consistent with surrounding code or an existing API.

# matching an external library's camelCase API
def setUp(self):           # unittest requires this exact name
    ...

# aligning related assignments can aid readability in some cases
x      = 1
longer = 2

Legitimate reasons: compatibility with code that predates PEP 8, conforming to a framework's required names, or when a rule genuinely hurts clarity in context. The rule of thumb: deviate only with a clear readability or compatibility justification, not out of laziness.