On 5/6/05, Steven Bethard <[EMAIL PROTECTED]> wrote: > On 5/6/05, Paul Moore <[EMAIL PROTECTED]> wrote: > > On 5/6/05, Steven Bethard <[EMAIL PROTECTED]> wrote: > > > PEP: XXX > > > Title: Enhanced Iterators > > > > Strawman question - as this is the "uncontroversial" bit, can this > > part be accepted as it stands? :-) > > FWIW, I'm +1 on this. Enhanced Iterators > * updates the iterator protocol to use .__next__() instead of .next() > * introduces a new builtin next() > * allows continue-statements to pass values to iterators > * allows generators to receive values with a yield-expression > The first two are, I believe, how the iterator protocol probably > should have been in the first place. The second two provide a simple > way of passing values to generators, something I got the impression > that the co-routiney people would like a lot.
At the same time it pretty much affects *only* the co-routiney people, so there's no hurry. I'd be happy with PEP 340 without all this too. I think one reason it ended up in that PEP is that an earlier version of the PEP called __next__() with an exception argument instead of having a separate__exit__() API. There's one alternative possible (still orthogonal to PEP 340): instead of __next__(), we could add an optional argument to the next() method, and forget about the next() built-in. This is more compatible (if less future-proof). Old iterators would raise an exception when their next() is called with an argument, and this would be a reasonable way to find out that you're using "continue EXPR" with an iterator that doesn't support it. (The C level API would be a bit hairier but it can all be done in a compatible way.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com