PEP 702: Type system support for deprecations

[JelleZijlstra]

This is the first time anyone other than me sees this document, so I welcome any feedback.

[hauntsaninja]

I think it's somewhat unfortunate to not issue a runtime warning (I imagine most users would ideally want one). The SC has also indicated they'd like static typing to feel more cohesive with the runtime, so we should try harder to find something that could work.

Should we have an opt-in kwarg a la Protocol's runtime_checkable? Type checkers could warn if we decorate an overload with runtime warning; we could even detect it at runtime if the decorators are in the right order. Decorating a class could cause __init__ to raise the warning? (I think the popular deprecated library does this; can just use similar semantics)

[hauntsaninja]

(Let me know if I should move this comment to discuss or typing-sig; I just didn't see a discussion link in there)

[JelleZijlstra]

Thanks for the feedback, but yes I think this is better directed to the discuss/typing-sig thread.

My plan is:

• Wait a few days to give people the chance to provide feedback on typos/organization/copyedits
• Merge the PEP
• Open discussions on both Discuss and typing-sig (since it's a typing PEP but also implicates the core development workflow

[ItsDrike]

Looks pretty good.

Though I actually think that introducing typing.Deprecated would be something worth while, due to some additional uses it provides.

Mainly when deprecating type-aliases, like: FOO_TYPE: TypeAlias = Union[A, B, C], it would be quite nice to be able to mark this type alias as deprecated with: FOO_TYPE: Deprecated[TypeAlias, "Replaced by BAR_TYPE"] = Union[A, B, C]. As this is currently completely impossible with the type system, and it's not even possible for a library to produce a runtime warning for these cases, which is why something like typing.Deprecated would be very nice to see.

[CAM-Gerlach]

Various minor suggestions and comments.

Trying out the new PEP checklist:

New PEP Checklist

• File created from the latest PEP template

Content requirements

• PEP topic discussed in a suitable venue and general agreement that a PEP is appropriate
• Content is reasonably sound, complete and makes at least basic technical sense
• Abstract and Copyright sections completed, with the required wording in the latter
• Suggested sections included (unless not applicable)
• Title clearly, accurately and concisely describes the content [See comment]
• Prose is intelligible and generally free of basic grammar and syntax errors, at least to the degree they significantly detract from understanding [Except as listed in comments]
• Code is in code blocks, well-formatted (PEP 7/PEP 8) and has the right lexer name if non-Python (or text)
• Any project stated in the PEP as supporting/endorsing benefiting from it confirms such None found

Technical requirements

• Filename in the correct format (pep-NNNN.rst)
• PEP, Title, Author, Status (Draft), Type and Created headers filled out correctly
• PEP-Delegate, Requires, Python-Version and Replaces filled out if appropriate
• Sponsor listed and approves if not authored by a core dev or PEP editor
• PEP builds with no warnings, CI checks pass and content displays as intended in the rendered preview [Except for as listed in comments]
• PEP number assigned by the PEP editors and filename & PEP header updated accordingly
• Sponsor/author(s) that are core devs/PEP editors added to .github/CODEOWNERS for the PEP
• Right before or after initial merging, PEP discussion thread created and linked to in Discussions-To and Post-History

[CAM-Gerlach]

LGTM from my side, pending resolution of Guido's final comments. Thanks @JelleZijlstra !

[JelleZijlstra]

Thanks everyone for the feedback!