[Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in

"Martin v. Löwis" martin at v.loewis.de
Mon Mar 5 19:36:23 CET 2007


Ka-Ping Yee schrieb:
> The iterator protocol in Python 2.x consists of two methods:
> ``__iter__()`` called on an iterable object to yield an iterator, and
> ``next()`` called on an iterator object to yield the next item in the
> sequence.  Using a ``for`` loop to iterate over an iterable object
> implicitly calls both of these methods.  This PEP proposes that the
> ``next`` method be renamed to ``__next__``, consistent with all the
> other protocols in Python in which a method is implicitly called as
> part of a language-level protocol

+1

> and that a built-in function named
> ``next`` be introduced to invoke ``__next__`` method, consistent with
> the manner in which other protocols are explicitly invoked.

-1. I dislike the introduction of more builtins unless they have a true
generality (i.e. are likely to be needed in many programs). For this 
one, I think the normal usage of __next__ will be with a for loop, so
I don't think one would often need an explicit next() invocation.

It is also not true that most protocols are explicitly invoked through
builtin functions. Instead, most protocols are can be explicitly invoked
through methods in the operator module. So following tradition, it
should be operator.next.

Of those protocols that are not operators, it is still not true that
they normally invocation through builtin functions is available. Things
like data attributes (__dict__, __slots__) don't have accessor 
functions; __class__ is accessed through type() (not class()), __init__
and __del__ don't have any wrappers although they are methods, same
for __copy__, __deepcopy__, __new__, __length_hint__; and reduce()
doesn't invoke __reduce__.

I do know that len(), str(), unicode() etc all call their protocols.
However, it is *not* the case that these builtin exists because
the protocol was first. It is vice versa: the builtin was there,
and a way was need to extend it for user-defined types.

As an alternative, I propose that object grows a .next() method,
which calls __next__ by default.

Please record this objection in the PEP even if you don't change
it otherwise.

Regards,
Martin


More information about the Python-3000 mailing list