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

Guido van Rossum guido at python.org
Tue Mar 6 21:21:10 CET 2007

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/)

More information about the Python-3000 mailing list