Repository navigation
Conversation
Also use the newer type var syntax in a few places.
Documentation build overview
419 files changed ·
|
| See :pep:`585` and :ref:`types-genericalias`. | ||
|
|
||
| .. class:: Type(Generic[CT_co]) | ||
| .. class:: Type[CT_co] |
There was a problem hiding this comment.
I think when I tried to do this during the PEP 695 implementation it wasn't possible because Sphinx couldn't parse the syntax, definitely supportive of changing this.
There was a problem hiding this comment.
This seems fine now:
- https://cpython-previews--154480.org.readthedocs.build/en/154480/library/typing.html#typing.Type
- https://cpython-previews--154480.org.readthedocs.build/en/154480/library/typing.html#typing.MutableSequence
Although I missed a few instances, which I will add.
|
|
||
| This is now an alias for :class:`typing.Union`. | ||
|
|
||
| .. deprecated:: 3.16 |
There was a problem hiding this comment.
Is it soft-deprecated or deprecated?
| .. deprecated:: 3.16 | |
| .. soft-deprecated:: 3.16 |
If it's soft deprecated, also add them to the relevant file in the deprecations docs. If it's regular-deprecated, please schedule removal for a version.
|
@JelleZijlstra @AlexWaygood Sorry to bother you, but could one of you review and merge this. While I only have 2 PRs open at the moment against CPython, I'm a bit worried about hitting the new 3 PR limit. |
No need to worry, we'll add you to the exclusion list. :-) |
Couldn't you have mentioned this after I strong-armed these two into merging this PR? 😇 |
|
I guess I don't need to do anything here? |
A review and (potential) merge would still be welcome, but became a bit less pressing for me. |
| * :class:`typing.Optional` in favor of the dedicated union syntax | ||
| (``X | None``) | ||
| * :class:`typing.NoReturn` in favor of :class:`typing.Never` | ||
| * :class:`typing.ForwardRef` in favor of :class:`annotationlib.ForwardRef` |
There was a problem hiding this comment.
These last two are actually just aliases. Perhaps it's clearer to mention them separately?
There was a problem hiding this comment.
What exactly do you have in mind? As a whole new top-level item, a new sub-list inside this item, or just change "The following typing-related classes are :term:soft deprecated:" to "The following typing-related classes and aliases ..."?
There was a problem hiding this comment.
I was thinking of just having two lists.
There was a problem hiding this comment.
I've done that, but it looks a bit weird to me to separate the aliases from the rest of the typing-related items.
| See :pep:`585` and :ref:`types-genericalias`. | ||
|
|
||
| .. class:: List(list, MutableSequence[T]) | ||
| .. class:: List[T](list, MutableSequence[T]) |
There was a problem hiding this comment.
Unrelated but presenting List as a subclass of list is somewhat confusing
There was a problem hiding this comment.
Indeed, but it's consistent with the other classes in this doc (e.g. Set[T](set, MutableSet[T])).
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
|
|
||
| * The following typing-related aliases are :term:`soft deprecated`: | ||
|
|
||
| * :class:`typing.NoReturn` in favor of :class:`typing.Never` |
There was a problem hiding this comment.
Sorry NoReturn is not an alias, but types.UnionType is.
There was a problem hiding this comment.
I've moved it. I think it would be cleanest to use sub-headers, i.e. one for "re module" and one for "Typing-related". And then use one bullet point per item. But I'm not sure if that's in the spirit of the document.
5 participants
Also use the newer type var syntax in a few places.
This PR does not deprecated
TypeVar,ParamSpec, andTypeVarTupleconstructors, as it is sometimes necessary to create type vars using the
explicit syntax. (For example to create a shared type var like
AnyStrorto use it as a type form.)
Cc @JelleZijlstra