Repository navigation
Remove PEP 9999 recommendation #2989
Description
Currently, PEP-1 recommends that new PEPs be submitted as "PEP 9999", and then a PEP number will be assigned by the PEP editors upon approval.
What happens in practice is that a PEP editor looks up the next available number when the PR is created and tells the author to use that. This feels like an unnecessary complication. I suggest that PEP authors should instead just pick the next available number when they create their PEP. If there is a conflict (e.g., two PEPs submitted around the same time with the same number), the PEP editors can pick which one gets which number.
Activity
Rosuav commentedon Jan 30, 2023
On the assumption that we don't often have huge numbers of PEPs awaiting numbers, this seems reasonable. But if it's ever wrong, it makes an annoying conflict (what if 705 is the next, but someone submits a PR with 706?).
We're programmers. Can we build ourselves a bot that watches for a PR that creates pep-9999.txt, and submits a change to it that picks the next number and renames the file? Not sure if a bot would have permission to edit a PR like that, though.
CAM-Gerlach commentedon Jan 31, 2023
Yup, #2956 already implements this per similar reasoning, at least in the new author-facing PEP checklists/PR templates. As a followup, we could revise PEP 1/PEP 12/etc. accordingly, though it is less critical now that the checklist/PR template will be the first-line step by step instructions for authors and reviewers when submitting a new PEP, as opposed to having to trawl through PEP 1 or 12 for those details.
In fact, it should be even better than that, as checking the open PRs will quickly show if any new PEP PRs are already open that have a specific number.
Then we're not worse off than if they submitted a PR with 9999, no? It just means that in a few cases, the file will still need a name change post PR submission (which is a hassle for authors and reviewers), instead of in all of them.
Sure, we could build that and it wouldn't be that hard (it would be fairly easy with GitHub Actions, in fact), but even that seems not worth the as the user could just enter the next number themselves to begin with instead of 9999 the various places, and it would need some heuristics and checking of the open PRs to guess what the next number should be (otherwise, it'll pick a conflicting number if another PR is already open), and that's still not 100% foolproof for all cases and would still require human review.
dstufft commentedon Jun 12, 2023
I think this is implemented now?