mirror of
https://github.com/python/cpython.git
synced 2025-07-07 19:35:27 +00:00
Docs: Fix some semantic usages of iterator.__iter__
(GH-130172)
These references to an `__iter__` method mean `object.__iter__`, not `iterator.__iter__`.
This commit is contained in:
parent
85f1cc8d60
commit
4d3a7ea354
3 changed files with 6 additions and 6 deletions
|
@ -719,7 +719,7 @@ Glossary
|
|||
iterables include all sequence types (such as :class:`list`, :class:`str`,
|
||||
and :class:`tuple`) and some non-sequence types like :class:`dict`,
|
||||
:term:`file objects <file object>`, and objects of any classes you define
|
||||
with an :meth:`~iterator.__iter__` method or with a
|
||||
with an :meth:`~object.__iter__` method or with a
|
||||
:meth:`~object.__getitem__` method
|
||||
that implements :term:`sequence` semantics.
|
||||
|
||||
|
|
|
@ -141,18 +141,18 @@ a helper class :class:`ABC` to alternatively define ABCs through inheritance:
|
|||
MyIterable.register(Foo)
|
||||
|
||||
The ABC ``MyIterable`` defines the standard iterable method,
|
||||
:meth:`~iterator.__iter__`, as an abstract method. The implementation given
|
||||
:meth:`~object.__iter__`, as an abstract method. The implementation given
|
||||
here can still be called from subclasses. The :meth:`!get_iterator` method
|
||||
is also part of the ``MyIterable`` abstract base class, but it does not have
|
||||
to be overridden in non-abstract derived classes.
|
||||
|
||||
The :meth:`__subclasshook__` class method defined here says that any class
|
||||
that has an :meth:`~iterator.__iter__` method in its
|
||||
that has an :meth:`~object.__iter__` method in its
|
||||
:attr:`~object.__dict__` (or in that of one of its base classes, accessed
|
||||
via the :attr:`~type.__mro__` list) is considered a ``MyIterable`` too.
|
||||
|
||||
Finally, the last line makes ``Foo`` a virtual subclass of ``MyIterable``,
|
||||
even though it does not define an :meth:`~iterator.__iter__` method (it uses
|
||||
even though it does not define an :meth:`~object.__iter__` method (it uses
|
||||
the old-style iterable protocol, defined in terms of :meth:`~object.__len__` and
|
||||
:meth:`~object.__getitem__`). Note that this will not make ``get_iterator``
|
||||
available as a method of ``Foo``, so it is provided separately.
|
||||
|
|
|
@ -949,9 +949,9 @@ Generator Types
|
|||
---------------
|
||||
|
||||
Python's :term:`generator`\s provide a convenient way to implement the iterator
|
||||
protocol. If a container object's :meth:`~iterator.__iter__` method is implemented as a
|
||||
protocol. If a container object's :meth:`~object.__iter__` method is implemented as a
|
||||
generator, it will automatically return an iterator object (technically, a
|
||||
generator object) supplying the :meth:`!__iter__` and :meth:`~generator.__next__`
|
||||
generator object) supplying the :meth:`~iterator.__iter__` and :meth:`~generator.__next__`
|
||||
methods.
|
||||
More information about generators can be found in :ref:`the documentation for
|
||||
the yield expression <yieldexpr>`.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue