GeezerVison is showing github.com — Document PEP 695 · Issue #103921 · python/cpython
DescriptionWe 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
ActivityFidget-Spinner commented on Apr 27, 2023 AlexWaygood commented on Apr 27, 2023
- 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 commented on May 19, 2023
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 commented on May 19, 2023 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 commented on May 19, 2023 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 commented on May 19, 2023
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 commented on May 26, 2023 Reacted by Hugo van Kemenade
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|