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 <[EMAIL PROTECTED]> wrote: > > "Guido van Rossum" <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
