Repository navigation
Mark remaining completed PEPs as Final #2872
Description
Activity
- addedmetaRelated to the repo itself and its processesRelated to the repo itself and its processes
on Nov 7, 2022 - changed the title
[-]Mark remaining completed PEPs as Final[/-][+]Meta: Mark remaining completed PEPs as Final[/+]on Nov 7, 2022 - changed the title
[-]Meta: Mark remaining completed PEPs as Final[/-][+]Mark remaining completed PEPs as Final[/+]on Nov 7, 2022 Thank you for tying the loose ends!
PEP-590 Vectorcall: a fast calling protocol for CPython is implemented, but there is currently active work in 3.12 to better expose both ends of the protocol via the CPython API, and have the changes in the Finalizing the API section been addressed?
The finalization was done in 3.9 as planned.
The API is being added to Limited API in 3.12, but that's not part of the PEP. Just more work in the area.
So, it should be marked Final.PEP-3121 Extension Module Initialization and Finalization: Accepted from all the way back in 3.0, but I'm not sure whether this should be considered Final yet, since its been a long time and there is still ongoing work in PEP 687 that might be related.
There were many PEPs that build on top of this one, and more are probably to come, but the API specified in PEP-3121 should still work – as it did in 3.0. This PEP should be Final as well.
As for typing PEPs, AFAIK many are still missing documentation.
Reacted by Erlend E. Aasland and C.A.M. GerlachThanks @encukou ! I've updated the list above to reflect both.
Thank you for providing this list @CAM-Gerlach! I can probably help out with some of these, but others are more than welcome to contribute as well.
Reacted by C.A.M. Gerlach and Hugo van Kemenade
The other PEPs that look like good candidates for being marked final are listed as follows. I've excluded PEPs that were approved for >3.11, refer to removals/changes planned for future version (e.g. PEP 594) or are otherwise known to be not yet final, and list special cases, PEPs I'm unsure about and typing PEPs (which may be contingent on implementation in mainstream type checkers) separately.
@gustavgransbo If you'd like to help, feel free to go ahead and submit a PR for each PEP, pinging any authors not already listed as codeowners.
The PEPs that are implemented in released versions and have no outstanding considerations I'm aware of:
There are also some special cases:
I'm not sure about the following:Implemented, but there is currently active work in 3.12 to better expose both ends of the protocol via the CPython API, and have the changes in the Finalizing the API section been addressed? @encukou @markshannon any insight here?Confirmed by @encukou to be fully implemented and should be marked Final; added above.Accepted from all the way back in 3.0, but I'm not sure whether this should be considered Final yet, since its been a long time and there is still ongoing work in PEP 687 that might be related. @encukou @erlend-aasland any insight?Confirmed by @encukou to be Final, as the API it describes is implemented and building on top of it is a topic for future PEPs.There's also the Accepted typing PEPs, which might also depend on implementation status in the major typecheckers as well as being formally documented the appropriate places, since that is generally the majority of actual implementation work; @JelleZijlstra would be much better informed about that. Here's the raw list:
Finally, I've left the 8000-series PEPs for a separate issue.
Footnotes
Typing-related, but principally deals with core CPython, not type checkers ↩