[Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342
Phillip J. Eby
pje at telecommunity.com
Fri Jun 17 03:53:11 CEST 2005
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.
More information about the Python-Dev
mailing list