Understanding the Python PEP Lifecycle Stages

This article outlines the standard progression of a Python Enhancement Proposal (PEP), detailing how a proposed feature, design change, or process update moves from an initial concept to official inclusion in the Python language. By exploring the formal stages defined in PEP 1—including drafting, review, acceptance, and final implementation—this guide provides a clear roadmap of the governance framework shaping Python's evolution.

1. Idea Inception and Pre-Draft Discussion

Before a proposal receives a formal PEP number, the idea begins in the community. The author typically initiates discussion on platforms such as the Python Discourse forum or the python-ideas mailing list. The objective of this phase is to gauge community interest, discover existing alternatives, and verify whether the idea justifies a full enhancement proposal.

2. Draft

Once vetted, the author creates a formal document following standard PEP formatting. A PEP editor reviews the proposal for structural compliance and assigns it a unique PEP number. In the Draft stage, the document undergoes continuous iterations, refining its technical specifications, motivation, rationale, and backwards compatibility impact.

3. Review and Deliberation

During this stage, the PEP is actively discussed across the Python community and core development team. The Python Steering Council—or a designated PEP Delegate (often referred to as a BDFL-Delegate)—is assigned to oversee the proposal. The author updates the text to address edge cases, technical trade-offs, and critical feedback raised during public deliberation.

4. Decision: Accepted or Rejected

Once consensus builds and the proposal reaches maturity, the Steering Council or the assigned delegate makes a formal ruling:

• Accepted: The proposal meets technical standards, aligns with Python's design philosophy, and is approved for implementation.
• Rejected: The proposal is declined. The PEP is retained in the archives alongside documented reasoning to prevent redundant future proposals.

5. Final (Implementation)

After a proposal is Accepted, the implementation must be developed, tested, and merged into the CPython codebase. Once the changes are committed and scheduled for release in an official version of Python, the status changes to Final. At this point, the PEP lifecycle is complete.

Alternate and Terminal States

Not all PEPs follow a linear path from draft to final release. Several alternative states exist to categorize proposals throughout their lifecycle:

• Deferred: The proposal is valid but postponed until specific prerequisites, resources, or dependencies become available.
• Withdrawn: The author voluntarily retracts the proposal due to insurmountable design flaws, lack of interest, or personal decision.
• Active: Used primarily for Informational or Process PEPs (such as PEP 1 itself) that are never "completed" because they serve as ongoing standards.
• Superseded: A previously accepted or finalized PEP is made obsolete by a newer proposal that replaces its specifications.