-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-45680: Clarify documentation on GenericAlias
objects
#29335
Conversation
The documentation on ``GenericAlias`` objects implies at multiple points that only container classes can define ``__class_getitem__``. This is misleading. This PR proposes a rewrite of the documentation to clarify that non-container classes can define ``__class_getitem__``, and to clarify what it means when a non-container class is parameterized. See also: initial discussion of issues with this piece of documentation in python#29308, and previous BPO issue [42280](https://bugs.python.org/issue42280).
containers' classes may call the classmethod :meth:`__class_getitem__` of the | ||
class instead. The classmethod :meth:`__class_getitem__` should return a | ||
``GenericAlias`` object. | ||
``GenericAlias`` objects are generally created by |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed the wording from "are created by subscripting a class" to "are generally created by subscripting a class". This is because it is certainly possible to directly instantiate a GenericAlias
object through types.GenericAlias
, as this documentation states later on.
Doc/library/stdtypes.rst
Outdated
* :class:`collections.abc.ValuesView` | ||
* :class:`contextlib.AbstractContextManager` | ||
* :class:`contextlib.AbstractAsyncContextManager` | ||
* :class:`dataclasses.Field` | ||
* :class:`functools.cached_property` | ||
* :class:`functools.partialmethod` | ||
* :class:`os.PathLike` | ||
* :class:`pathlib.Path` | ||
* :class:`pathlib.PurePath` | ||
* :class:`pathlib.PurePosixPath` | ||
* :class:`pathlib.PureWindowsPath` | ||
* :class:`queue.LifoQueue` | ||
* :class:`queue.Queue` | ||
* :class:`queue.PriorityQueue` | ||
* :class:`queue.SimpleQueue` | ||
* :ref:`re.Pattern <re-objects>` | ||
* :ref:`re.Match <match-objects>` | ||
* :class:`shelve.Shelf` | ||
* :class:`types.MappingProxyType` | ||
* :class:`weakref.WeakKeyDictionary` | ||
* :class:`weakref.WeakMethod` | ||
* :class:`weakref.WeakSet` | ||
* :class:`weakref.WeakValueDictionary` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Fidget-Spinner, is this list currently in any particular order at all? 🙂 I can think of a few possible orderings that might work:
- Fully alphabetise the list
- Go through the modules in alphabetical order, but list classes within each module according to the order they appear in in the module's
__all__
. - Something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left some remarks. Generally looks good, but I do not use the typing features of Python, so I'll wisely keep my mouth shut regarding most of these changes ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I won't be able to respond so quickly due to IRL stuff. Sorry if I take a week or more!
Of course, no worries! Apologies it ended up being such a large PR! |
Co-authored-by: Erlend Egeberg Aasland <[email protected]>
|
||
These standard library collections support parameterized generics. | ||
The following standard library classes support parameterized generics. This |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was discussion on the previous PR that I opened on how to introduce this list. @ambv suggested "The following standard library data structures [...]" — I've gone for "The following standard library classes [...]" as I think the definition of "class" is probably easier to grok than the definition of "data structure".
Usually, the :ref:`subscription <subscriptions>` of container objects calls the | ||
method :meth:`__getitem__` of the object. However, the subscription of some | ||
containers' classes may call the classmethod :meth:`__class_getitem__` of the | ||
class instead. The classmethod :meth:`__class_getitem__` should return a | ||
``GenericAlias`` object. | ||
|
||
.. note:: | ||
If the :meth:`__getitem__` of the class' metaclass is present, it will take | ||
precedence over the :meth:`__class_getitem__` defined in the class (see | ||
:pep:`560` for more details). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This material has been moved to the docs for __class_getitem__
in the data model, per @Fidget-Spinner's suggestion (see #29389)
GenericAlias
objectsGenericAlias
objects and __class_getitem__
I hope it's okay if I leave this PR in the capable hands of @Fidget-Spinner . |
This comment has been minimized.
This comment has been minimized.
…`` in the data model (pythonGH-29389) 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 pythonGH-29335.
Friendly ping, @ambv 🙂 |
Ping, @ambv, @Fidget-Spinner 🙂 any chance of getting this merged soon? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor formatting suggestions, I will apply them myself then merge.
Thanks @AlexWaygood for the PR, and @Fidget-Spinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.9, 3.10. |
…H-29335) The documentation on ``GenericAlias`` objects implies at multiple points that only container classes can define ``__class_getitem__``. This is misleading. This PR proposes a rewrite of the documentation to clarify that non-container classes can define ``__class_getitem__``, and to clarify what it means when a non-container class is parameterized. See also: initial discussion of issues with this piece of documentation in pythonGH-29308, and previous BPO issue [42280](https://bugs.python.org/issue42280). Also improved references in glossary and typing docs. Fixed some links. Co-authored-by: Erlend Egeberg Aasland <[email protected]> Co-authored-by: Ken Jin <[email protected]> (cherry picked from commit 0eae9a2) Co-authored-by: Alex Waygood <[email protected]>
Sorry, @AlexWaygood and @Fidget-Spinner, I could not cleanly backport this to |
GH-30688 is a backport of this pull request to the 3.10 branch. |
Hooray! Thanks, @Fidget-Spinner 😀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AlexWaygood no problem. Thanks for your patience and seeing this through.
…H-29335) The documentation on ``GenericAlias`` objects implies at multiple points that only container classes can define ``__class_getitem__``. This is misleading. This PR proposes a rewrite of the documentation to clarify that non-container classes can define ``__class_getitem__``, and to clarify what it means when a non-container class is parameterized. See also: initial discussion of issues with this piece of documentation in pythonGH-29308, and previous BPO issue [42280](https://bugs.python.org/issue42280). Also improved references in glossary and typing docs. Fixed some links. Co-Authored-By: Erlend Egeberg Aasland <[email protected]> Co-Authored-By: Ken Jin <[email protected]> Co-Authored-By: Alex Waygood <[email protected]>
GH-30689 is a backport of this pull request to the 3.9 branch. |
…H-29335) (GH-30688) The documentation on ``GenericAlias`` objects implies at multiple points that only container classes can define ``__class_getitem__``. This is misleading. This PR proposes a rewrite of the documentation to clarify that non-container classes can define ``__class_getitem__``, and to clarify what it means when a non-container class is parameterized. See also: initial discussion of issues with this piece of documentation in GH-29308, and previous BPO issue [42280](). Also improved references in glossary and typing docs. Fixed some links. Co-authored-by: Erlend Egeberg Aasland <[email protected]> Co-authored-by: Ken Jin <[email protected]> (cherry picked from commit 0eae9a2) Co-authored-by: Alex Waygood <[email protected]> Automerge-Triggered-By: GH:Fidget-Spinner
…H-29335) (GH-30689) The documentation on ``GenericAlias`` objects implies at multiple points that only container classes can define ``__class_getitem__``. This is misleading. This PR proposes a rewrite of the documentation to clarify that non-container classes can define ``__class_getitem__``, and to clarify what it means when a non-container class is parameterized. See also: initial discussion of issues with this piece of documentation in GH-29308, and previous BPO issue [42280](https://bugs.python.org/issue42280). Also improved references in glossary and typing docs. Fixed some links. (cherry picked from commit 0eae9a2) Co-Authored-By: Erlend Egeberg Aasland <[email protected]> Co-Authored-By: Ken Jin <[email protected]> Co-Authored-By: Alex Waygood <[email protected]>
…ythonGH-29335) (pythonGH-30689) The documentation on ``GenericAlias`` objects implies at multiple points that only container classes can define ``__class_getitem__``. This is misleading. This PR proposes a rewrite of the documentation to clarify that non-container classes can define ``__class_getitem__``, and to clarify what it means when a non-container class is parameterized. See also: initial discussion of issues with this piece of documentation in pythonGH-29308, and previous BPO issue [42280](https://bugs.python.org/issue42280). Also improved references in glossary and typing docs. Fixed some links. (cherry picked from commit 0eae9a2) Co-Authored-By: Erlend Egeberg Aasland <[email protected]> Co-Authored-By: Ken Jin <[email protected]> Co-Authored-By: Alex Waygood <[email protected]>
The documentation on
GenericAlias
objects implies at multiple points thatonly container classes can define
__class_getitem__
. This is misleading.This PR proposes a rewrite of the documentation to clarify that non-container
classes can define
__class_getitem__
, and to clarify what it means when anon-container class is parameterized.
The PR also proposes some changes to the list of standard library classes that
define
__class_getitem__
. This PR proposes adding several classes to the list,to make it somewhat more complete. However, more importantly, it attempts
to clarify that the list is not intended to be an exhaustive enumeration of
every single standard-library class that defined
__class_getitem__
.See also: initial discussion of issues with this piece of documentation in
#29308, and previous BPO issue 42280.
https://bugs.python.org/issue45680