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-47122: Fix the table of methods in the collections.abc documentation #32090
base: main
Are you sure you want to change the base?
Conversation
Doc/library/collections.abc.rst
Outdated
:class:`Collection` [1]_ :class:`Sized`, ``__contains__``, | ||
:class:`Reversible` [1]_ :class:`Iterable` ``__reversed__``, | ||
``__iter__`` | ||
:class:`Generator` [1]_ :class:`Iterator` ``send``, Inherited mixin :class:`Iterator` method, |
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 would leave the Generator as is. The "inherited" references are used only when the would copy a lot of methods. The current form for this entry is more readable, useful, and easy to understand.
``__setitem__``, ``pop``, ``popitem``, ``clear``, ``update``, | ||
``__delitem__``, and ``setdefault`` | ||
``__delitem__``, ``setdefault`` | ||
``__iter__``, |
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.
Please don't do these minor stylistic edits. It makes the table harder to read.
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 reverted most of them.
Doc/library/collections.abc.rst
Outdated
``__iter__``, ``clear``, ``pop``, ``remove``, ``__ior__``, | ||
``__len__``, ``__iand__``, ``__ixor__``, and ``__isub__`` | ||
``__contains__``, ``__iand__``, ``__ixor__``, ``__isub__`` |
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 Github diff makes it difficult to see what exactly what is changing here. Are you taking out the required len method, if so why?
Also put the "and" back in.
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.
Sorry for the unfriendly diff. I did not remove __len__
, I just reordered the abstract methods from contains
, iter
, len
to len
, iter
, contains
, so that it matches the order of the inherited classes Sized
, Iterable
, Container
of Collection
to improve readibility.
I also removed the ‘and’ for readability as it looks like the __and__
method, and because it was not used consistently in the table (every list of three items or more should have it).
What do you think?
Doc/library/collections.abc.rst
Outdated
:class:`Set` ``__iter__`` | ||
:class:`ValuesView` :class:`MappingView`, ``__contains__``, ``__iter__`` | ||
:class:`Collection` | ||
:class:`ItemsView` :class:`MappingView`, Inherited mixin :class:`MappingView` method, |
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 group of edits is harsh on the eyes. I don't see how they add any value. ISTM these all refactor the presentation style in a way that makes the table even harder to read and use.
Doc/library/collections.abc.rst
Outdated
@@ -220,7 +213,7 @@ Collections Abstract Base Classes -- Detailed Descriptions | |||
ABC for classes that provide the :meth:`__iter__` method. | |||
|
|||
Checking ``isinstance(obj, Iterable)`` detects classes that are registered | |||
as :class:`Iterable` or that have an :meth:`__iter__` method, but it does | |||
as or inherit from :class:`Iterable`, or that have an :meth:`__iter__` method, but it does |
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 is probably unnecessary. First, isinstance() always detects direct inheritance so that does need to be repeated every time we talk about isinstance(). Second, all classes that inherit from Iterable will already have an iter method so that case is covered by the current sentence.
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
Can you make a simplified version of this PR that sticks to fixing entries that are incorrect (like the missing clear method) rather than stylistic edits (eliding "and", general restyling, propagating the "inherited from" wording, general wording edits, etc.)? This table has been very successful in help users, but it is already challenging to read. IMO a number of these edits make less approachable or useful for day to day programming. With some of the edits a user would be better of running |
Thanks for the review. Sorry for the unfriendly diff: I have reverted the reordering of the methods and the removal of newlines after multiline entries. I have also restored footnote 2 and removed the propagation of the ‘inherited from’ wording for single inherited methods as suggested. Finally, I have commented about the elided ‘and’. This will hopefully make the P.R. more reviewable. I have made the requested changes; please review again. |
Thanks for making the requested changes! @rhettinger: please review the changes made to this pull request. |
|
||
:class:`MutableSequence` :class:`Sequence` ``__getitem__``, Inherited :class:`Sequence` methods and | ||
:class:`MutableSequence` :class:`Sequence` ``__getitem__``, Inherited mixin :class:`Sequence` methods, |
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.
What is the benefit of adding the word mixin
here?
A downside is that readers may wonder if mixin methods
or inherited mixin methods
are a special thing, which they aren’t. So I would not add the word, inherited Sequence methods
is fine.
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.
It is to refer only to mixing methods of the parent class, as the other parent methods do not belong to this column.
This pull request makes the following changes to the table of methods in the
collections.abc
documentation:Reversible
: add__iter__
abstract method;Generator
: replace__iter__
with inherited mixinIterator
method;MutableSequence
: addclear
mixin method;Set
: remove__ne__
mixin method (not defined here but inobject
), add__rand__
mixin method, add__ror__
mixin method, add__rsub__
mixin method, add__rxor__
mixin method;Mapping
: remove__ne__
mixin method (not defined here but inobject
);ItemsView
: add inherited mixinMappingView
method and inherited mixinSet
methods;KeysView
: add inherited mixinMappingView
method and inherited mixinSet
methods;ValuesView
: add inherited mixinMappingView
method;Coroutine
: add__await__
abstract method;AsyncGenerator
: replace__aiter__
with inherited mixinAsyncIterator
method;collections.abc.Iterable
description.https://bugs.python.org/issue47122