Skip to content
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

[doc] bpo-45680: Disambiguate __getitem__ and __class_getitem__ in the data model. #29389

Merged
merged 11 commits into from
Nov 18, 2021

Conversation

AlexWaygood
Copy link
Member

@AlexWaygood AlexWaygood commented Nov 3, 2021

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 #29335.

https://bugs.python.org/issue45680

…`` in the

data model.

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 python#29335.
Copy link
Member

@Fidget-Spinner Fidget-Spinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job!

Doc/reference/datamodel.rst Outdated Show resolved Hide resolved
Doc/reference/datamodel.rst Outdated Show resolved Hide resolved
Doc/reference/datamodel.rst Outdated Show resolved Hide resolved
@AlexWaygood AlexWaygood changed the title [doc] bpo-45680: Disambiguate __getitem__ and __class_getitem__ in the data model. [doc] bpo-45680: Disambiguate __getitem__ and __class_getitem__ in the data model. Nov 4, 2021
@AlexWaygood
Copy link
Member Author

Great job!

Thank you <3

@gvanrossum gvanrossum removed their request for review November 4, 2021 13:54
Copy link
Contributor

@ambv ambv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is pretty cool, thanks for being so thorough.

Doc/reference/datamodel.rst Outdated Show resolved Hide resolved
Doc/reference/datamodel.rst Outdated Show resolved Hide resolved
Doc/reference/datamodel.rst Outdated Show resolved Hide resolved
Doc/reference/datamodel.rst Outdated Show resolved Hide resolved
Doc/reference/datamodel.rst Outdated Show resolved Hide resolved
Doc/reference/datamodel.rst Outdated Show resolved Hide resolved
@AlexWaygood
Copy link
Member Author

This is pretty cool, thanks for being so thorough.

Massive thanks for the detailed review! I've rewritten large chunks in response 😅

(Wow, writing documentation is hard!)


Usually, the :ref:`subscription<subscriptions>` of an object using square
brackets will call the :meth:`~object.__getitem__` instance method defined on
the object's class. However, if the object being subscribed is itself a class,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be "object being subscribed", or "object being subscripted"?

Comment on lines 2285 to 2302
def subscribe(obj, x):
class_of_obj = type(obj)

# If the class of `obj` defines `__getitem__()`,
# call `type(obj).__getitem__()`
if hasattr(class_of_obj, '__getitem__'):
return class_of_obj.__getitem__(obj, x)

# Else, if `obj` defines `__class_getitem__()`,
# call `obj.__class_getitem__()`
elif hasattr(obj, '__class_getitem__'):
return obj.__class_getitem__(x)

# Else, raise an exception
else:
raise TypeError(
f"'{class_of_obj.__name__}' object is not subscriptable"
)
Copy link
Member Author

@AlexWaygood AlexWaygood Nov 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please correct me if this isn't quite right -- I'm in a little over my head here!

@AlexWaygood AlexWaygood requested a review from ambv November 7, 2021 22:40
@AlexWaygood
Copy link
Member Author

Okay, the CI failures are because rstlint.py reckons I've applied bad markup in lines 2292, 2297, 2315, 2323, 2337 and 2340. All of these are because rstlint sees things like "`obj`" and raises an error, because it reckons that it should either be something like "``obj``" or ":class:`obj`" -- it doesn't realise that I'm not actually trying to apply reStructuredText markup at all, as these are all inside comments inside code blocks.

@ambv ambv merged commit 31b3a70 into python:main Nov 18, 2021
@ambv ambv added needs backport to 3.9 only security fixes needs backport to 3.10 only security fixes labels Nov 18, 2021
@miss-islington
Copy link
Contributor

Thanks @AlexWaygood for the PR, and @ambv for merging it 🌮🎉.. I'm working now to backport this PR to: 3.9.
🐍🍒⛏🤖

@miss-islington
Copy link
Contributor

Thanks @AlexWaygood for the PR, and @ambv for merging it 🌮🎉.. I'm working now to backport this PR to: 3.10.
🐍🍒⛏🤖 I'm not a witch! I'm not a witch!

@bedevere-bot bedevere-bot removed the needs backport to 3.9 only security fixes label Nov 18, 2021
@bedevere-bot
Copy link

GH-29619 is a backport of this pull request to the 3.9 branch.

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Nov 18, 2021
…`` 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.
(cherry picked from commit 31b3a70)

Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
@bedevere-bot
Copy link

GH-29620 is a backport of this pull request to the 3.10 branch.

@bedevere-bot bedevere-bot removed the needs backport to 3.10 only security fixes label Nov 18, 2021
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Nov 18, 2021
…`` 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.
(cherry picked from commit 31b3a70)

Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
ambv added a commit that referenced this pull request Nov 18, 2021
…titem__`` in the data model (GH-29389) (GH-29620)

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.
(cherry picked from commit 31b3a70)

Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
ambv added a commit that referenced this pull request Nov 18, 2021
…item__`` in the data model (GH-29389) (GH-29619)

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.
(cherry picked from commit 31b3a70)

Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
@AlexWaygood AlexWaygood deleted the class_getitem-docs branch November 18, 2021 17:52
remykarem pushed a commit to remykarem/cpython that referenced this pull request Dec 7, 2021
…`` 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir skip news
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants