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

[Phillip J. Eby]

At 08:24 PM 6/16/2005 -0400, Raymond Hettinger wrote:
>Looking back at the history of 288, generator attributes surfaced only
>in later drafts.  In the earlier drafts, the idea for passing arguments
>to and from running generators used an argument to next() and a return
>value for yield.  If this sounds familiar, it is because it is not much
>different from the new PEP 342 proposal.  However, generator argument
>passing via next() was shot down early-on.  The insurmountable concept
>flaw was an off-by-one issue.  The very first call to next() does not
>correspond to a yield statement; instead, it corresponds to the first
>lines of a generator (those run *before* the first yield).  All of the
>proposed use cases needed to have the data passed in earlier.

Huh?  I don't see why this is a problem.  PEP 342 says:

"""When the *initial* call to __next__() receives an argument that is not 
None, TypeError is raised; this is likely caused by some logic error."""


>With the death of that idea, generator attributes were born as a way of
>being able to pass in data before the first yield was encountered and to
>receive data after the yield.  This was workable and satisfied the use
>cases.  Coroutine simulations such as those in Dr Mertz's articles were
>easily expressed with generator attributes.  As a further benefit, using
>attributes was a natural approach because that same technique has long
>been used with classes (so no new syntax was needed and the learning
>curve was zero).

Ugh.  Having actually emulated co-routines using generators, I have to tell 
you that I don't find generator attributes natural for this at all; 
returning a value or error (via PEP 343's throw()) from a yield expression 
as in PEP 342 is just what I've been wanting.


>In contrast to PEP 288's low impact approach, PEP 342 changes the
>implementation of the for-loop, alters the semantics of "continue",
>introduces new and old-style iterators, and creates a new magic method.

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.


>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.


>IOW, I don't follow how 342 got this far, how 342 intends to overcome
>the off-by-one issue,

It explicitly addresses it already.


>  how it addresses all of the other objections
>leveled at the now dead PEP 288

Arguments for waiting aren't the same thing as arguments for never 
doing.  I interpret the comments in 288's history as ranging from -0 to +0 
on the yield expr/next(arg) issue, and didn't see any -1's except on the 
generator attribute concept.


>and why no one appears concerned about
>introducing yet another new-style/old-style issue that will live in
>perpetuity.

I believe it has been brought up before, and I also believe I pointed out 
once or twice that __next__ wasn't needed.  I think Guido even mentioned 
something to that effect himself, but everybody was busy with PEP 
340-inspired ideas at the time.  342 was split off in part to avoid losing 
the ideas that were in it.