What is a PEP?
Python Enhancement Proposals (PEPs) are the documents that govern Python’s evolution. Each one proposes a new language feature, collects community input on a design question, or records a decision already made. Accepted PEPs are the authoritative source for how a feature works.
Not every PEP is accepted. Rejected PEPs often contain useful context about what was tried and why it did not fit.
What a PEP contains
Each PEP follows a standard structure:
- An abstract summarizing the proposal
- Motivation and rationale
- Technical specification
- Alternatives considered
- References
Three kinds of PEPs
Standards Track PEPs propose new features or behaviors for Python itself. Informational PEPs document design guidelines without mandating any change. Process PEPs propose changes to how Python is developed, governed, or discussed.
PEPs that shaped modern Python
A handful of PEPs define the Python most developers use today:
- PEP 8 established the style guide for the standard library, the basis for formatters like Ruff.
- PEP 484 introduced type hints and the
typingmodule, which tools like mypy, Pyright, and ty implement. - PEP 517 and PEP 518 replaced
setup.py-only builds with a standard hook API and introduced pyproject.toml. - PEP 621 standardized project metadata inside
pyproject.toml, which uv, Poetry, and Hatch all now support.
Learn More
- peps.python.org is the full index of all PEPs
- What is PEP 8? covers the style guide every Python linter enforces
- What is PEP 484? covers the foundation of Python’s type-checking ecosystem
- What is PEP 517/518? explains the modern packaging build interface
- What is PEP 621? explains standardized project metadata in pyproject.toml