Document PEP 695

[JelleZijlstra]

We should document PEP-695 for Python 3.12 (issue #103763, PR #103764 for implementation). I am leaving docs out of the PR to avoid complicating an already huge PR with a tight deadline, but let's start thinking about what we need to document:

• New AST nodes in ast.rst
• Language reference should be updated to include the new grammar changes
• Language reference should be updated to reflect new scoping rules (https://docs.python.org/3.12/reference/executionmodel.html#naming-and-binding)
• typing.rst should list the PEP
• typing.rst should mention that TypeVar gained an infer_variance argument and that it now supports lazily evaluated bounds/constraints
• Examples of generics in typing.rst should use the new syntax
• typing.rst should document the new TypeAliasType
• typing.TypeAlias should be mentioned as deprecated (including in the deprecation timeline at the bottom of typing.rst), and any examples of type aliases should be updated to use the new syntax
• New opcodes need to be mentioned in dis.rst. dis.dis docs should mention new contexts where nested code objects can appear. The CALL_INTRINSIC_1 and 2 opcodes should mention the new intrinsics.

Linked PRs

• gh-103921: Document PEP 695 #104642
• gh-103921: Rename "type" header in argparse docs #104654
• [3.12] gh-103921: Document PEP 695 (GH-104642) #104989
• [3.11] gh-103921: Improve typing documentation (GH-104642) #105007
• gh-103921: Minor PEP-695 fixes to the ast module docs #105093
• [3.12] gh-103921: Minor PEP-695 fixes to the ast module docs (GH-105093) #105101

[Fidget-Spinner]

Ideally we should also add the new builtin types to the list of stdtypes https://docs.python.org/3/library/stdtypes.html#type-annotation-types-generic-alias-union

IMO, they ought to belong there instead of typing.rst as typing.rst is for the stdlib module.

[AlexWaygood]

• Examples of generics in typing.rst should use the new syntax

I agree that we should make sure that PEP 695 is presented as the idiomatic, modern way of writing generic functions and classes. But I'd like us to make sure that the old-style way of doing things also continues to be well documented in typing.rst, with plenty of examples. Many projects will continue to use the old way of defining generics for a long time after the release of Python 3.12, so that they'll be able to continue supporting older versions of Python. Unlike most other typing features, it will be impossible for us to backport most of PEP 695 to typing_extensions — we can't backport a syntax change.

[JelleZijlstra]

Ideally we should also add the new builtin types to the list of stdtypes https://docs.python.org/3/library/stdtypes.html#type-annotation-types-generic-alias-union

IMO, they ought to belong there instead of typing.rst as typing.rst is for the stdlib module.

I'm not sure about this. The types still claim that their __module__ is typing, and they are accessible as e.g. typing.TypeVar. I feel they'd be more discoverable in the typing docs than the stdtypes page.

[AlexWaygood]

I agree with @Fidget-Spinner. types.GenericAlias and types.UnionType both claim that their module is types, but we only have "stub entries" for them in types.rst; the extensive documentation for these classes is in stdtypes.rst:

>>> type(list[int]).__module__
'types'
>>> type(int | str).__module__
'types'

Builtin types that have dedicated syntax should all be documented in the same place (stdtypes.rst).

[JelleZijlstra]

I know, and I don't really like how the docs for GenericAlias and UnionType are organized; they'd probably also be cleaner if more of the docs were under types.

As a contrary example, types.ModuleType documents its attributes at https://docs.python.org/3.10/library/types.html#types.ModuleType, even though it claims its module is __builtins__.

Concrete problems I see with documenting these types in stdtypes:

• What would we put in typing.rst about them? We'll need to put some reference to the stdtypes description.
• It's going to be natural to refer to e.g. :class:typing.TypeVar elsewhere in the docs, but that would link to a stub description in the typing docs.

My preference would be to keep the main documentation for TypeVar etc. in typing.rst, but add a note about them to https://docs.python.org/3.10/library/stdtypes.html#type-annotation-types-generic-alias-union.

[AlexWaygood]

I know, and I don't really like how the docs for GenericAlias and UnionType are organized; they'd probably also be cleaner if more of the docs were under types.

Fair enough, I've also thought this in the past.

I see the point about not wanting to break all cross-references to TypeVar, ParamSpec, etc. -- it makes sense to leave those where they are. TypeAliasType still feels like it belongs next to the docs for UnionType and GenericAlias, to me. But, I agree that there's not perfect solution, and don't have a hugely strong opinion.

[AlexWaygood]

I think we're done here!