You, the PEP author, fork the PEP repository, and create a file named pep-NNNN.rst that contains your new PEP. NNNN should be the next available PEP number not used by a published or in-PR PEP.
However, I note that “should” is not “must”…
Was the number 728 skipped over for a specific reason? Should/may I claim that? Or would it be better to skip ahead to 734? (We are quickly approaching 754 (rejected), which number seems to have been chosen because it concerns IEEE-754 support. I assume that I should not just start at 755 and skip the numbers in between.)
Also, what happened to PEPs 300, 388, 716 and 717?
Ah, it didn’t occur to me to check outstanding pull requests as well. It seems there’s also a PR for PEP 734 (to supersede PEP 554), so I guess I would be submitting PEP 735.
Okay, there’s a chicken-and-egg aspect to this that I’m not understanding. It seems as if figuring out the number, setting up a discussion thread that goes in Discussions-To, and submitting the pull request are supposed to somehow happen all at once… ? PEP 1/12 definitely don’t make the intended flow/order obvious to me.
In particular, how can I open the PR if the PR entails adding a file that’s supposed to have the number populated (and giving it a corresponding name), but the number isn’t assigned until after the PR is open?
Make sure you find a sponsor or core dev co-author during the idea/drafting stage. Use 9999 when drafting. When they’re happy it’s ready for submission, check the next available number, rename, and open the PR. It’s unlikely for that number to be taken by someone else during those couple of minutes.
Some background: it used to be that PEPs were opened as 9999, then a PEP editor would come along later and assign the number. But we can skip that and let the author take the next available right away.
Discussions-To is indeed a bit /, but comes when PR is merged.
As soon as a PEP number has been assigned and the draft PEP is committed to the PEP repository, a discussion thread for the PEP should be created to provide a central place to discuss and review its contents, and the PEP should be updated so that the Discussions-To header links to it.
Two options: either right before merge or just after, open the discussion thread and update Discussions-To (and Post-History).
It’s probably easiest to do it after merge, with a quick followup PR to add the link.
Overview:
Float the idea, find a sponsor/core dev co-author
Draft the PEP with 9999
When sponsor/co-author happy, check next number, rename file, and open PR
Thanks. Should the other thread be moved back to the Packaging section, and/or renamed, then? Or what?
This is a packaging PEP, so a core dev co-author doesn’t seem to make much sense. If any code actually needs to be written I’d expect it to be in the Pip codebase, not CPython. I hoped a sponsor would eventually volunteer in the other thread, assuming anyone likes the idea
Move: I think so, yes. There are some “Draft PEP: …” and “PEP xx: …” topics in the PEPs section, but you’ll hopefully get more visibility and useful feedback in the Packaging one.
And PEP 1 says:
Each PEP must have a champion – someone who writes the PEP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The PEP champion (a.k.a. Author) should first attempt to ascertain whether the idea is PEP-able. Posting to the Ideas category of the Python Discourse is usually the best way to go about this, unless a more specialized venue is appropriate, such as the Typing category (for static typing ideas) or Packaging category (for packaging ideas) on the Python Discourse.
A core dev sponsor is still required - they do not have to be a co-author. Please see the details in PEP 1. There are some specific details for packaging PEPs here but they do not override the need for a sponsor.
I found those as well; I figured them to be deliberate and that there was no plan to fill in the gaps.
PEP 20 and PEP 42 are given special numbers so that there’s a ‘reserved’ section for ordinary meta-PEPs. PEP 20 is the Zen of Python, whereas PEP 42 appears to have been a long-obsolete, makeshift bug tracker. (That number was presumably chosen as a Douglas Adams reference). Presumably, a hypothetical future PEP 14 would also be a meta-PEP.
Not counting the Zen, PEP 101 seems to have been the first informational PEP, and the name was chosen for the classroom-setting joke. PEP 102 is a follow-on to it. While PEP 100 was written earlier, it seems that it was only retroactively made into a PEP.
It looks like PEP 103 was a relatively “ordinary” PEP after that, but then the numbers 160 and 200 were used to present the Python 1.6 and 2.0 release schedules, respectively (using those numbers for easy identification). Only after that, everyone finally started counting neatly from 201 onward.
Except of course for the ones related to planning for 3.x, and the governance PEPs. (Namespaces are one honking great idea – let’s do more of those! ) And for a few other numbers chosen for the joke: 404 (to assert that there wouldn’t be a Python 2.8), 666 (a rejected proposal for what I’d call a precursor to tabnanny, chosen presumably because mixed whitespace is “evil”), 754 (regarding IEEE-754), 801 (“reserved” as some obscure music reference), and perhaps others.
/
, but comes when PR is merged.
Moved, title adjusted, and edited to reflect the current status.
) And for a few other numbers chosen for the joke: 404 (to assert that there wouldn’t be a Python 2.8), 666 (a rejected proposal for what I’d call a precursor to