~ 3 min read
What is a PEP and Why Should I Care?
No doubt if you’ve been developing in Python for any length of time, you will have heard the acronym “PEP” mentioned quite frequently. More often than not you hear it when talking about Python code style, usually followed by the number “8”. So what is a PEP and why should you care?
What is a PEP?
PEP stands for “Python Enhancement Proposal”. They are used to describe and summarise the technical design and reasons for enhancements to Python and surrounding processes. Each PEP is followed by a number, which never changes. They are written with the core developers of Python as the main audience.
The “What’s New in Python ..” posts written with each release list the PEPs that have been implemented in each release. Here’s the latest one for Python 3.9.
PEP Types
There are 3 kinds of PEP descriptions:
- Standards Track: Describes a new feature or implementation
- Informational: Describes a design issue or guidelines
- Process: Describes a change to process surrounding Python, but not to Pythons’ codebase.
How are PEP’s decided?
PEPs are initially discussed on the python-ideas email list before being written formally by a author/co-author. A PEP author then submits a PR to the PEP repository containing the proposed PEP. If none of the authors are core-developers, then a sponsor (author mentor) is needed to guide an author through this the PEP submission workflow. A PEP is reviewed by a PEP editor and if the PEP passes all standards checks and is approved, it is assigned a number. The Python steering council hold the final say in whether a PEP should be accepted or rejected.
Why should you care about PEPs?
Although the primary audience of PEP’s isn’t necessarily a developer who just happens to use Python, PEPs are available to all to read. I find it interesting to dig into the details of why a particular set of decisions has been made in a particular way. Being able to see the entire technical document describing how a new feature works at the point it becomes readily available as part of a Python release is incredibly useful, where a quick summary might not suffice. I need not wait for other developers to document how they work as I can see for myself.
It’s also very useful to have a documented process (as Part of PEP1) how any developer might go about suggesting and making improvements to the Python language that they feel would be a benefit. This makes the process accessible to any developer.
Interesting PEPs
Below are a number of interesting PEP’s I found over the course of my research for this post. Enjoy!
| PEP# | Description |
|---|---|
| PEP0 | Index of PEPs. Lists all the PEPs with links to descriptions of each of them. |
| PEP1 | PEP purpose and guidelines. A Meta-PEP - This PEP describes a PEP. |
| PEP8 | Style Guide for Python Code. The PEP every Python developer will have heard of, describes the code conventions for making sure Python code is readable. |
| PEP20 | The Zen of Python. Another famous PEP. A simple description of the BDFL’s (Guido Van Rossum’s) major guiding principles for Pythons design. |
| PEP508 | Dependency specification for Python Software Packages |
| PEP631 | Dependency Specification for pyproject.toml - How packages may be specified in the new pyproject.toml (related: using Poetry to publish to PyPI using this) |
| PEP3333 | The Python 3 version of the Web Server Gateway Interface (WSGI) protocol |
| PEP3156 | The asyncio module - Asynchronous I/O in Python 3.3+ |