[{"data":1,"prerenderedAt":66},["ShallowReactive",2],{"qa-\u002Fpython\u002Fidioms\u002Fpep8-style":3},{"page":4,"siblings":56,"blog":47},{"id":5,"title":6,"body":7,"description":11,"difficulty":14,"extension":15,"framework":16,"frameworkSlug":17,"meta":18,"navigation":19,"order":12,"path":20,"questions":21,"related":47,"seo":48,"seoDescription":49,"stem":50,"subtopic":51,"topic":52,"topicSlug":53,"updated":54,"__hash__":55},"qa\u002Fpython\u002Fidioms\u002Fpep8-style.md","Pep8 Style",{"type":8,"value":9,"toc":10},"minimark",[],{"title":11,"searchDepth":12,"depth":12,"links":13},"",2,[],"easy","md","Python","python",{},true,"\u002Fpython\u002Fidioms\u002Fpep8-style",[22,26,30,34,38,42],{"id":23,"difficulty":14,"q":24,"a":25},"what-is-pep8","What is PEP 8?","**PEP 8** is the official **style guide for Python code** — a set of conventions for\nformatting and naming that make code **consistent and readable** across the\ncommunity. It's a *recommendation*, not a language rule: code that violates PEP 8\nstill runs fine, but consistency aids collaboration.\n\n```python\n# PEP 8 style\ndef calculate_total(items, tax_rate=0.0):\n    subtotal = sum(items)\n    return subtotal * (1 + tax_rate)\n\n# not PEP 8 — cramped, inconsistent spacing\u002Fnaming\ndef calcTotal(items,taxRate=0.0):\n    subTotal=sum(items);return subTotal*(1+taxRate)\n```\n\nPEP 8 covers indentation (4 spaces), naming, whitespace, imports, and line length.\nIts guiding principle: **readability counts**, since code is read far more often than\nit's written.\n",{"id":27,"difficulty":14,"q":28,"a":29},"naming-conventions","What are PEP 8's naming conventions?","PEP 8 assigns a distinct case to each kind of name so readers can tell them apart at\na glance. **`snake_case`** for functions, variables, and modules;\n**`PascalCase`** (CapWords) for classes; **`UPPER_SNAKE_CASE`** for constants. A\nsingle leading underscore signals \"internal\".\n\n```python\nMAX_RETRIES = 3                  # constant — UPPER_SNAKE_CASE\n\nclass HttpClient:                # class — PascalCase\n    def send_request(self):      # method — snake_case\n        retry_count = 0          # variable — snake_case\n        self._session = None     # _leading underscore = \"internal\"\n```\n\nAvoid single-character names like `l`, `O`, `I` (they look like digits). Method\u002F\nfunction names use the same `snake_case` as variables; only classes and exceptions\nuse `PascalCase`.\n",{"id":31,"difficulty":14,"q":32,"a":33},"imports-line-length","What does PEP 8 say about imports and line length?","**Imports** go at the **top** of the file, **one per line**, grouped in order:\nstandard library, third-party, then local — separated by blank lines. For **line\nlength**, PEP 8 recommends a maximum of **79 characters** (72 for docstrings\u002F\ncomments), though many modern teams relax this to 88 or 100.\n\n```python\n# standard library\nimport os\nimport sys\n\n# third-party\nimport requests\n\n# local\nfrom myapp.utils import helper\n\n# avoid: import os, sys   (multiple on one line)\n```\n\nKeeping imports sorted and grouped makes dependencies obvious. The line-length cap\nkeeps code readable in side-by-side diffs and narrow editors; tools like `isort`\nautomate import ordering.\n",{"id":35,"difficulty":14,"q":36,"a":37},"zen-of-python","What is the Zen of Python?","The **Zen of Python** (PEP 20) is a collection of **19 guiding aphorisms** that\ncapture Python's design philosophy. You can read it any time by running\n**`import this`**. It informs *why* the language and its idioms look the way they do.\n\n```python\nimport this\n# Beautiful is better than ugly.\n# Explicit is better than implicit.\n# Simple is better than complex.\n# Readability counts.\n# There should be one-- and preferably only one --obvious way to do it.\n# ...and 14 more\n```\n\nThe aphorisms favor **clarity, simplicity, and explicitness** over cleverness. They\naren't enforced rules but a cultural compass — when two approaches compete, the Zen\nusually points to the more Pythonic one.\n",{"id":39,"difficulty":14,"q":40,"a":41},"formatters-linters","What are black and ruff, and how do formatters differ from linters?","A **formatter** automatically **rewrites** your code into a consistent layout; a\n**linter** **analyzes** code and **reports** style violations and likely bugs without\n(usually) changing it. **black** is the dominant formatter (opinionated,\nnear-zero-config); **ruff** is an extremely fast linter (and formatter) that\nconsolidates many older tools.\n\n```python\n# before black\nx = {'a':1,'b':2}\n# after black\nx = {\"a\": 1, \"b\": 2}\n\n# command line\n# black .          -> reformats files in place\n# ruff check .     -> reports lint issues\n# ruff check --fix -> auto-fixes what it can\n```\n\nRunning a formatter ends style arguments in code review (the tool decides), while a\nlinter catches unused imports, undefined names, and anti-patterns. Most teams run\nboth, often automatically via pre-commit hooks or CI.\n",{"id":43,"difficulty":44,"q":45,"a":46},"when-break-pep8","medium","When is it acceptable to break PEP 8?","PEP 8 itself says **\"A Foolish Consistency is the Hobgoblin of Little Minds\"** —\nstyle serves readability, so break the rules when following them would make code\n**less readable** or when you must stay consistent with **surrounding code** or an\nexisting API.\n\n```python\n# matching an external library's camelCase API\ndef setUp(self):           # unittest requires this exact name\n    ...\n\n# aligning related assignments can aid readability in some cases\nx      = 1\nlonger = 2\n```\n\nLegitimate reasons: compatibility with code that predates PEP 8, conforming to a\nframework's required names, or when a rule genuinely hurts clarity in context. The\nrule of thumb: **deviate only with a clear readability or compatibility\njustification**, not out of laziness.\n",null,{"description":11},"Python interview questions on PEP 8, naming conventions, imports and line length, the Zen of Python, formatters and linters like black and ruff, and when it is acceptable to break PEP 8.","python\u002Fidioms\u002Fpep8-style","PEP 8 & Style","Pythonic Idioms","idioms","2026-06-18","XZbVx5iojwhWxTkdsYPJmC4TKVdwn0NbvswTvPh9UZ0",[57,61,62],{"subtopic":58,"path":59,"order":60},"EAFP vs LBYL","\u002Fpython\u002Fidioms\u002Feafp-lbyl",1,{"subtopic":51,"path":20,"order":12},{"subtopic":63,"path":64,"order":65},"Common Gotchas & Anti-patterns","\u002Fpython\u002Fidioms\u002Fgotchas",3,1781808682394]