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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
