PEP 808: Mark as Accepted

[henryiii]

• SC/PEP Delegate has formally accepted/rejected the PEP and posted to the Discussions-To thread
• Pull request title in appropriate format (PEP 123: Mark as Accepted)
• Status changed to Accepted/Rejected
• Resolution field points directly to SC/PEP Delegate official acceptance/rejected post, including the date (e.g. `01-Jan-2000 <https://discuss.python.org/t/12345/100>`__)
• Acceptance/rejection notice added, if the SC/PEP delegate had major conditions or comments
• Discussions-To, Post-History and Python-Version up to date

[read-the-docs-community]

Documentation build overview

📚 pep-previews | 🛠️ Build #32784693 | 📁 Comparing a641dc2 against latest (c1f8b92)

  🔍 Preview build  

701 files changed · ± 701 modified

± Modified

• index.html
• numerical/index.html
• pep-0000/index.html
• pep-0001/index.html
• pep-0002/index.html
• pep-0003/index.html
• pep-0004/index.html
• pep-0005/index.html
• pep-0006/index.html
• pep-0007/index.html
• and 691 more...

[henryiii]

There was one minor comment:

There is one relatively minor point that should be clarified when transferring the specification into the official standards documentation. The PEP states:

If a field is present in both places, then the build backend is allowed to insert entries into the list or table, but not remove entries, reorder entries, or modify the entries.

This does not put any restrictions on where entries may be inserted - at the start, at the end, or in the middle. In practice, none of the existing fields affected by this PEP assign any meaning to ordering, so this doesn’t matter, but in order to avoid confusion should a future PEP add an order-dependent field, the specification should be explicit. Allowing insertions either anywhere, or just at the end, is fine with me - I’ll leave it to the PEP author to choose.

I think that means the PEP can be accepted as is, then when updating the spec at packaging.python.org this needs to be clarified, and a note is not needed here, but happy to add one if preferred. I think we have picked one, but I rather want to look at what it affects over the next couple days when preparing implementations before settling one one vs. the other.