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

[Raymond Hettinger]

PEP 288 is now withdrawn.  The generator exceptions portion is subsumed
by PEP 343, and the generator attributes portion never garnered any
support.

The fate of generator attributes is interesting vís-a-vís PEP 342.  The
motivation was always related to supporting advanced generator uses such
as emulating coroutines and writing generator based data consumer
functions.  At the time, Guido and everyone else found those use cases
to be less than persuasive.  Also, people countered that that
functionality could be easily simulated with class based iterators,
global variables, or passing a mutable argument to a generator.
Amazingly, none of those objections seem to be directed toward 342 which
somehow seems on the verge of acceptance even without use cases, clear
motivation, examples, or a draft implementation.

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

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.
Meanwhile, it hasn't promised any advantages over the dead PEP 288
proposals.

IOW, I don't follow how 342 got this far, how 342 intends to overcome
the off-by-one issue, how it addresses all of the other objections
leveled at the now dead PEP 288, and why no one appears concerned about
introducing yet another new-style/old-style issue that will live in
perpetuity.


Raymond



Sidenote: generator attributes also failed because generators lacked a
sufficiently elegant way to refer to running instances of themselves
(there is no self argument so we would need an access function or have a
dynamic function attribute accessible only from within a running
generator).