Home Original page

PEP 288: Generator Attributes

Rocco Moretti roccomoretti at netscape.net
Sun Dec 8 22:09:02 EST 2002 
bokr at oz.net (Bengt Richter) wrote in message news:<asjh27$80v$0 at 216.39.172.122>...
> I saw this in the python-dev summary:
> 
> ===================================
> `PEP 288:  Generator Attributes`__
> ===================================

The attribute passing scheme seems to be complex and cumbersome. The
process of set attributes -> call processing function -> repeat is an
akward way of achieving what you really want to do - continue the
generator with given data. I'd agree with what Guido said on
Python-Dev: there is no advantage in this scheme over passing a
mutable dummy object when the generator is created (you could even
call it __self__ if you really wanted too ...).

That said, I'm still not sure what the actual objections to the
previous (rejected) alternative are. I think that the reason for the
empty/ignored .next() is obvious if you understand how generators
work, and I question why this is a show-stopper issue (you'll never
see it if you never pass values to generators). I get the impression
that there are other reasons people have for being against using
.next() (and generator value passing in general) that aren't mentioned
in the PEP - it would be nice to get them down for posterity.

I would also quibble with RH's assertation that the unused first
.next(value) problem is "intractable." If we're open to using magic
locals (as in the __self__ value proposed), you could just use a magic
local to store the parameter passed to the generator (__genval__?,
__nextval__?). If you also allowed yield to return the value as well
(as in: invalue = yield outvalue) you could (in most cases) circumvent
Guido's complaint that "__self__ is butt-ugly."

As for GvR's issue of why generator passing is better than passing a
dummy object at the creation of the generator, it is, in essence, the
same argument for why true object orientation is better than emulating
it in C: when presented simply, the concept flows more naturally.
(Note the following argument flownders a bit for the current PEP) The
.next(value) passing method frames itself as a symetric dialog between
two functions (I give you data, you reply, I give you data ...).
Whereas the using of a dummy object presents itself more as an
asymetric, type-up-a-memo-and-post-it-on-the-bulletin-board type
arrangement. Besides- it adds another entity you have to keep track
of.

sig.__Limerick__ = '''
There once was a young man from Occam,
Whose rhetorical theories would shock them.
"When entities multiply,
Your arguments die.
So please use my razor to dock them."
'''

P.S. I believe further PEP division may be called for. Value passing
and exception throwing in generators are synergystic, yes, but can be
implemented independantly if need be. The chance of passing at least
one may be increased if split into separate PEPs, instead of having
their separate destinies thrown into a common PEP number.
More information about the Python-list mailing list