[Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342

Guido van Rossum gvanrossum at gmail.com
Fri Jun 17 05:03:49 CEST 2005


On 6/16/05, Raymond Hettinger <python at rcn.com> wrote:
>  [Phillip]
> > I could definitely go for dropping __next__ and the next() builtin from PEP
> > 342, as they don't do anything extra.  I also personally don't care about
> > the new continue feature, so I could do without for-loop alteration
> > too.  I'd be perfectly happy passing arguments to next() explicitly; I just
> > want yield expressions.
> 
> That's progress!  Please do what you can to get the non-essential
> changes out of 342.

Here's my current position: instead of g.__next__(arg) I'd like to use
g.next(arg). The next() builtin then isn't needed.

I do like "continue EXPR" but I have to admit I haven't even tried to
come up with examples -- it may be unnecessary. As Phillip says, yield
expressions and g.next(EXPR) are the core -- and also incidentally
look like they will cause the most implementation nightmares. (If
someone wants to start implementing these two now, go right ahead!)

> > >Meanwhile, it hasn't promised any advantages over the dead PEP 288
> > >proposals.
> >
> > Reading the comments in PEP 288's revision history, it sounds like the
> > argument was to postpone implementation of next(arg) and yield expressions
> > to a later version of Python, after more community experience with
> > generators.  We've had that experience now.
> 
> 288 was brought out of retirement a few months ago.  Guido hated every
> variation of argument passing and frequently quipped that data passing
> was trivially accomplished though mutable arguments to a generator,
> through class based iterators, or via a global variable.  I believe all
> of those comments were made recently and they all apply equally to 342.

That was all before I (re-)discovered yield-expressions (in Ruby!),
and mostly in response to the most recent version of PEP 288, with its
problem of accessing the generator instance. I now strongly feel that
g.next(EXPR) and yield-expressions are the way to go.

Making g.next(EXPR) an error when this is the *initial* resumption of
the frame was also a (minor) breakthrough. Any data needed by the
generator at this point can be passed in as an argument to the
generator.

Someone should really come up with some realistic coroutine examples
written using PEP 342 (with or without "continue EXPR").

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list