PEP Process — Core Concepts

Why the PEP process matters

Python serves tens of millions of developers. Every language change — a new keyword, a modified behaviour, even a deprecation — has downstream consequences. The PEP process exists to manage this complexity: it forces proposals through structured scrutiny before they can alter the language.

Understanding PEPs matters even if you never write one. Reading accepted PEPs teaches you why features exist, not just how to use them. Reading rejected PEPs teaches you what the language deliberately avoids.

What is a PEP?

A PEP is a design document, written in reStructuredText, stored in the peps repository on GitHub. Each PEP has a number (assigned sequentially), an author, a status, and a type.

PEP types

Type	Purpose	Examples
Standards Track	New feature or behaviour change	PEP 572 (walrus operator), PEP 484 (type hints)
Informational	General guideline or design rationale	PEP 20 (Zen of Python), PEP 257 (docstrings)
Process	Change to the development process itself	PEP 13 (governance), PEP 1 (PEP purpose and guidelines)

PEP statuses

• Draft — Under active discussion and revision.
• Accepted — Approved by the Steering Council; awaiting implementation.
• Final — Implemented and released.
• Rejected — Declined after review.
• Withdrawn — Author pulled the proposal.
• Deferred — Postponed indefinitely.
• Superseded — Replaced by a newer PEP.

The lifecycle of a PEP

1. Pre-PEP discussion. The author posts the idea on discuss.python.org (the Ideas category). Community feedback determines whether the idea is worth formalizing.

2. Drafting. The author writes the PEP following the template in PEP 12. Key sections include Abstract, Motivation, Specification, Backwards Compatibility, Security Implications, and Rejected Ideas.

3. PEP number assignment. A PEP editor (a volunteer role) reviews the format, assigns a number, and merges the draft into the peps repository.

4. Discussion period. The PEP is announced on discuss.python.org. Developers debate specifics. The author revises the PEP — sometimes through dozens of iterations.

5. Pronouncement. For Standards Track PEPs, the Steering Council makes the final decision. They may accept, reject, or request further revision. The decision and rationale are recorded in the PEP itself.

6. Implementation. Accepted PEPs are implemented as CPython pull requests. The PEP status moves to Final once the implementation ships in a release.

Anatomy of a well-written PEP

The best PEPs share common traits:

• Clear motivation. Not “this would be cool” but “here is a real problem that affects real code, with examples.”
• Concrete specification. Exact syntax, exact semantics, exact error messages.
• Backwards compatibility analysis. What existing code would break? How will migration work?
• Rejected alternatives. What other designs were considered and why were they worse?
• Reference implementation. A working branch that proves the idea is feasible.

PEP 572 (the walrus operator) is a masterclass in this structure. It documents years of discussion, multiple rejected syntaxes, and a clear rationale for the final choice.

Common misconception

Many people believe that only core developers can write PEPs. In fact, anyone can author a PEP. The requirement is a well-reasoned proposal and willingness to engage with community feedback. Several impactful PEPs have come from developers who were not core contributors at the time.

That said, writing a PEP is a significant commitment. Expect weeks or months of discussion and revision. The bar for acceptance is deliberately high because every accepted feature becomes permanent baggage the language carries forever.

One thing to remember: PEPs are Python’s institutional memory. They record not just what was decided, but why — and what was intentionally left out. Reading PEPs is the fastest way to understand the design philosophy behind the language.