The documentation explaining Python's data model does not adequately explain
the differences between ``__getitem__`` and ``__class_getitem__``, nor does it
explain when each is called. There is an attempt at explaining
``__class_getitem__`` in the documentation for ``GenericAlias`` objects, but
this does not give sufficient clarity into how the method works. Moreover, it
is the wrong place for that information to be found; the explanation of
``__class_getitem__`` should be in the documentation explaining the data model.
This PR has been split off from GH-29335.
``typing.Tuple`` has been deprecated since Python 3.9, so it makes no sense to mention it so prominently in the documentation for the ``typing`` module.
The list of PEPs at the top of the documentation for the ``typing`` module has
become too long to be readable. This PR proposes presenting this
information in a more structured and readable way by adding a new "relevant
PEPs" section to the ``typing`` docs.
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
* Use "X | Y" instead of "Union" where it makes sense.
* Mention that "X | Y" is equivalent to "Union[X, Y]" in Union section.
* Remove "Optional[X]" as shorthand for "Union[X, None]" as the new
shorthand is now "X | None".
* Mention that "Optional[X]" can be written as "X | None" in section
about "Optional".
Co-authored-by: Ken Jin <28750310+Fidget-Spinner@users.noreply.github.com>
Follow up to 7cdf30fff3 and 4173320920. This addresses the point "1. Update links in typing, subscription and union to point to GenericAlias." in the bpo for this PR.
This special marker annotation is intended to help in distinguishing
proper PEP 484-compliant type aliases from regular top-level variable
assignments.
This shows users that they can use the actual types. Using deprecated types is confusing.
This also prefers colections.abc.Sized instead of the alias typing.Sized. I guess the aliases were created to make it convenient to import all collections related types from the same place.
This should be backported to 3.9.
Automerge-Triggered-By: @gvanrossum
* bpo-39491: Merge PEP 593 (typing.Annotated) support
PEP 593 has been accepted some time ago. I got a green light for merging
this from Till, so I went ahead and combined the code contributed to
typing_extensions[1] and the documentation from the PEP 593 text[2].
My changes were limited to:
* removing code designed for typing_extensions to run on older Python
versions
* removing some irrelevant parts of the PEP text when copying it over as
documentation and otherwise changing few small bits to better serve
the purpose
* changing the get_type_hints signature to match reality (parameter
names)
I wasn't entirely sure how to go about crediting the authors but I used
my best judgment, let me know if something needs changing in this
regard.
[1] 8280de241f/typing_extensions/src_py3/typing_extensions.py
[2] 17710b8798/pep-0593.rst
PR #4906 changed the typing.Generic class hierarchy, leaving an
outdated comment in the library reference. User-defined Generic ABCs now
must get a abc.ABCMeta metaclass from something other than typing.Generic
inheritance.
This PR replaces the old note mentioning that `typing` is a provisional module with a new one mentioning types are not enforced at runtime. I am not sure if there was any official announcement about making `typing` non-provisional, but _de-facto_ no new features were added during Python 3.7, and no backwards incompatible changes were made except for few small things that were considered bugs.
https://bugs.python.org/issue37814:
> The empty tuple syntax in type annotations, `Tuple[()]`, is not obvious from the examples given in the documentation (I naively expected `Tuple[]` to work); it has been documented in PEP 484 and in mypy, but not in the documentation for the typing module.
https://bugs.python.org/issue37814
This is an old feature request that appears from time to time. After a year of experimenting with various introspection capabilities in `typing_inspect` on PyPI, I propose to add these two most commonly used functions: `get_origin()` and `get_args()`. These are essentially thin public wrappers around private APIs: `__origin__` and `__args__`.
As discussed in the issue and on the typing tracker, exposing some public helpers instead of `__origin__` and `__args__` directly will give us more flexibility if we will decide to update the internal representation, while still maintaining backwards compatibility.
The implementation is very simple an is essentially a copy from `typing_inspect` with one exception: `ClassVar` was special-cased in `typing_inspect`, but I think this special-casing doesn't really help and only makes things more complicated.
I tried to get rid of the `_ProtocolMeta`, but unfortunately it didn'y work. My idea to return a generic alias from `@runtime_checkable` made runtime protocols unpickleable. I am not sure what is worse (a custom metaclass or having some classes unpickleable), so I decided to stick with the status quo (since there were no complains so far). So essentially this is a copy of the implementation in `typing_extensions` with two modifications:
* Rename `@runtime` to `@runtime_checkable` (plus corresponding updates).
* Allow protocols that extend `collections.abc.Iterable` etc.
The implementation is straightforward, it just mimics `ClassVar` (since the latter is also a name/access qualifier, not really a type). Also it is essentially copied from `typing_extensions`.
In order to support typing checks calling hex(), oct() and bin() on user-defined classes, a SupportIndex protocol is required. The ability to check these at runtime would be good to add for completeness sake. This is pretty much just a copy of SupportsInt with the names tweaked.
* Replace external recipe link with a link to the dataclasses module.
* Highlight the class definition syntax for typing.NamedTuple
and add an example for clarity.
Currently, the docs state that when doing `Type[X]`, X is only allowed to
be a class, a union of classes, and Any. This pull request amends
that sentence to clarify X may also be a typevar (or a union involving
classes, Any, and TypeVars).
* Fix PEP 8 (SomeType instead of some_type)
* Add a function parameter annotation
* Explain, using wording from PEP 484 and PEP 526,
why one annotation is in quotes and another is not.
Suggested by Ivan Levkevskyi.
James Hilton-Balfe
Jelle Zijlstra
Michael Oliver
Nikita Sobolev
Alex Waygood
Micael Jarniac
DonnaDia
Sebastian Rittau
Maximilian Hils
Ori Avtalion
Ken Jin
andrei kulakov
DevilXD
Paul Bryan
Johan Dahlin
John Belmonte
Yurii Karabas
Dominik1123
Andre Delfino
Saiyang Gou
abdo
Mikhail Golubev
Patrick Reader
MingZhe Hu
Irit Katriel
Luciano Ramalho
Zackery Spytz
ziheng
Serhiy Storchaka
Miss Islington (bot)
ananthan-123
Jakub Stasiak
Ivan Levkivskyi
M. Eric Irrgang
Josh Holland
Anthony Sottile
Paul Dagnelie
cocoatomo
Raymond Hettinger
Jack Wilsdon
Ville Skyttä
Boštjan Mejak
Ismo Toijala
Stéphane Wirtel
Michael Lee
Travis DePrato
Sebastian Rittau
Éric Araujo
topper-123
khyox
Mathias Rav
Mariatta
Berker Peksag