[Python-3000] PEP: rename it.next() to it.next(), add a next() built-in (original) (raw)
Brett Cannon brett at python.org
Wed Mar 7 22:15:23 CET 2007
- Previous message: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
- Next message: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 3/7/07, Georg Brandl <g.brandl at gmx.net> wrote:
Ka-Ping Yee schrieb: > On Wed, 7 Mar 2007, Georg Brandl wrote: >> Ka-Ping Yee schrieb: >> > On Tue, 6 Mar 2007, Guido van Rossum 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. >> > >> > Okay, this is checked in as PEP 3114. >> >> Patch is at http://python.org/sf/1675363. > > Thanks for doing this work!
I hope it helps getting a decision about the PEP. One thing that struck me while doing the next -> next transition was the new asymmetry between generator methods; there is now send() and close(), but no next() anymore.
Oooh, that's a good point. I guess that would mean generators should keep their 'next' methods for API symmetry with 'send' and 'close'; calling next() just for when you are not sending something in would be icky.
But of course having two methods that do the exact same thing seems a little icky as well. I was on the fence with this whole proposal, but this makes me -0 on the rename and +0 on the new built-in.
-Brett
- Previous message: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
- Next message: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]