Skip to content

Mark remaining completed PEPs as Final #2872

Closed
@CAM-Gerlach

Description

@CAM-Gerlach

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:

  • PEP-602 Annual Release Cycle for Python: Should be recategorized as an Active Process PEP: PEP 602: Mark as Active Process #3736
  • PEP-581 Using GitHub Issues for CPython: Since the PEP's content is tightly focused on the rationale for choosing GitHub rather than the current, active process for using it and is thus now of historical rather than procedural value, it should be marked Final (rather than Active) like other transition-oriented Process PEPs have: PEP 581: Mark as Final #3807

I'm not sure about the following:

  • PEP-590 Vectorcall: a fast calling protocol for CPython: 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.
  • 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. @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:

544                   Protocols: Structural subtyping (static duck typing)  typing
563                                    Postponed Evaluation of Annotations  typing
586                                                          Literal Types  typing
589        TypedDict: Type Hints for Dictionaries with a Fixed Set of Keys  typing
591                                     Adding a final qualifier to typing  typing
593                             Flexible function and variable annotations  typing
604                                 Allow writing union types as ``X | Y``  typing
612                                      Parameter Specification Variables  typing
613                                                  Explicit Type Aliases  typing
646                                                      Variadic Generics  typing
647                                               User-Defined Type Guards  typing
655  Marking individual TypedDict items as required or potentially-missing  typing
673                                                              Self Type  typing
675                                          Arbitrary Literal String Type  typing
681                                                  Data Class Transforms  typing

Finally, I've left the 8000-series PEPs for a separate issue.

Footnotes

  1. Typing-related, but principally deals with core CPython, not type checkers

Metadata

Metadata

Assignees

No one assigned

    Labels

    metaRelated to the repo itself and its processes

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions