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

[Guido van Rossum]

I don't see much point of adding the builtin if we don't rename the
method to __next__, since that would just make the wart stick out
more. The conversion pain is a one-time cost. We can work with 2to3
and Python 2.6 warnings on the conversions. Hey, if we can "from
__future__ import dict_views" then I think we can "from __future__
import next"! Even if the converter can't do a perfect job, it should
be possible to write 2.6 code on which the converter *does* do a
perfect job, simply by avoiding a few odd corner cases.

--Guido

On 3/6/07, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> "Guido van Rossum" <guido at python.org> wrote:
> > Having now read this entire thread I am going to accept Ping's PEP.
> > Adding the sentinel argument to the next() builtin was what did it for
> > me: it neatly solves the problem if having to catch that StopIteration
> > in 99% of the cases.
>
> Have you read the post by Thomas Wouters in regards to .next() vs.
> .__next__() [1]?  The idea is that methods that *shouldn't* be called
> from user code explicitly have generally received __magic__ methods,
> while methods that have uses-cases for being called directly get
> nonmagic methods.
>
> He (and I believe most everyone) is in favor of some two-argument
> builtin or otherwise named next(interator, default=), it's the bulk
> renaming of .next -> .__next__ that is the real point of contention
> (with non-iterator .next methods, .next instance variables, etc.)
>
>  - Josiah
>
>
> [1] http://mail.python.org/pipermail/python-3000/2007-March/006010.html
>
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)