Skip to content

bpo-32717: Document PEP 560 #6726

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

Merged
merged 3 commits into from
May 8, 2018
Merged

Conversation

ilevkivskyi
Copy link
Member

@ilevkivskyi ilevkivskyi commented May 8, 2018

I am sorry for a delay! Finally, here are the docs.

Attn: @gvanrossum

https://bugs.python.org/issue32717

@ilevkivskyi
Copy link
Member Author

@ned-deily I am not sure about 3.7 policies now about documentation. This is a purely documentation PR, is it OK to backport this to Python 3.7 between now and final release?

@ned-deily
Copy link
Member

Bug fixes appropriate for a maintenance release and doc updates are ok for 370rc1.

@ilevkivskyi
Copy link
Member Author

Bug fixes appropriate for a maintenance release and doc updates are ok for 370rc1.

OK, thanks!

Copy link
Member

@serhiy-storchaka serhiy-storchaka left a comment

Choose a reason for hiding this comment

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

Would be nice to add an index entry for __mro_entries__.


Resolve MRO entries dynamically as specified by :pep:`560`.

This function looks for items in ``bases`` that are not instances of
Copy link
Member

Choose a reason for hiding this comment

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

*bases*

Parameters are marked up so.

Resolve MRO entries dynamically as specified by :pep:`560`.

This function looks for items in ``bases`` that are not instances of
:func:`type`, and returns a tuple where each such object that has
Copy link
Member

Choose a reason for hiding this comment

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

:class:`type`?

:func: adds ().


This function looks for items in ``bases`` that are not instances of
:func:`type`, and returns a tuple where each such object that has
an ``__mro_entries__`` method is replaced with an unpacked result of
Copy link
Member

Choose a reason for hiding this comment

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

I would write :meth:`__mro_entries__`.

Copy link
Member Author

Choose a reason for hiding this comment

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

This actually makes visually inconsistent with how __prepare__ appears here and elsewhere, so I would keep it as is.

.. method:: class.__class_getitem__(cls, args)

Return an object representing the specialization of a generic class
by type arguments found in ``args`` tuple.
Copy link
Member

Choose a reason for hiding this comment

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

*args*

I would rename args to key. It is not always a tuple.

One can implement the generic class syntax as specified by :pep:`484`
(for example ``List[int]``) by defining a special method

.. method:: class.__class_getitem__(cls, args)
Copy link
Member

Choose a reason for hiding this comment

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

object, not class.

I would use classmethod as for __init_subclass__.

This method is looked up on the class object itself, and when defined in
the class body, this method is implicitly a class method.

.. note:: This mechanism is primarily reserved for use with static type
Copy link
Member

Choose a reason for hiding this comment

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

Does it work? This style looks uncommon. I would start the note from the new line.

Or better remove the note directive at all. It attracts much attention, but it doesn't look too important.

Copy link
Member Author

Choose a reason for hiding this comment

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

It actually worked, but I would just remove it.

Initially :pep:`484` was designed in such way that it would not introduce *any*
changes to the core CPython interpreter. Now type hints and the :mod:`typing`
module are extensively used by the community, so this restriction is removed.
The PEP introduces two special methods ``__class_getitem__`` and
Copy link
Member

Choose a reason for hiding this comment

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

:meth:`__class_getitem__`

More links is good in What's New.

@ilevkivskyi
Copy link
Member Author

@serhiy-storchaka Thanks for review! I now addressed your comments, please take a look again.

@ilevkivskyi ilevkivskyi merged commit bd5f965 into python:master May 8, 2018
@miss-islington
Copy link
Contributor

Thanks @ilevkivskyi for the PR 🌮🎉.. I'm working now to backport this PR to: 3.7.
🐍🍒⛏🤖

@ilevkivskyi ilevkivskyi deleted the document-pep-560 branch May 8, 2018 18:38
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request May 8, 2018
(cherry picked from commit bd5f965)

Co-authored-by: Ivan Levkivskyi <[email protected]>
@bedevere-bot
Copy link

GH-6729 is a backport of this pull request to the 3.7 branch.

miss-islington added a commit that referenced this pull request May 8, 2018
(cherry picked from commit bd5f965)

Co-authored-by: Ivan Levkivskyi <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants