PEP Process — ELI5

Imagine your school wants to add a new rule — like “pizza every Friday.” Someone cannot just start ordering pizzas. They have to write down the idea, explain why it is good, let everyone discuss it, and then the student council votes. If it passes, pizza shows up in the cafeteria. If it does not pass, no pizza — but the idea is saved in case someone wants to try again later.

Python works the same way. When someone wants to add a new feature to the language, they write a document called a PEP — short for Python Enhancement Proposal. A PEP explains what the feature is, why Python needs it, and how it would work.

Then the discussion begins. Other Python developers read the PEP and share opinions. They might say “great idea!” or “this would break my code” or “what about this edge case?” The author updates the PEP based on feedback, sometimes rewriting it several times.

Finally, a small group of trusted decision-makers — the Steering Council — reads everything and decides: accepted, rejected, or “go back and revise.” If accepted, someone writes the code, and the feature appears in the next version of Python.

Every major Python feature went through this process. The with statement, f-strings, the walrus operator := — all started as PEPs. Even the rules about how Python itself is governed are defined in PEPs.

The beautiful part is that every PEP is public. Anyone can read the full history of why Python looks the way it does.

One thing to remember: A PEP is Python’s way of making sure every change is thought through, discussed, and documented before it becomes part of the language everyone uses.