[Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340

[Guido van Rossum]

On 5/6/05, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 5/6/05, Paul Moore <p.f.moore at gmail.com> wrote:
> > On 5/6/05, Steven Bethard <steven.bethard at gmail.com> 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/)