PEP 288: Generator Attributes

[John Roth]

"Rocco Moretti" <roccomoretti at netscape.net> wrote in message
news:ff133276.0212081908.fa8ad69 at posting.google.com...
> 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 ...).

I thoroughly agree. I've been looking at this entire discussion
with some bemusement, because, for me at least, the most
intuitive thing to do is make yield a built in function rather than
a statement. That way, it can return a value, which is what
was passed in on the reinvocation.

The trouble with the whole thing is that conceptually, "yield" has two
values: one that it returns to the caller, and one that it
gets from the caller. It's a two way pipe.

Making yield a statement effectively forclosed the option of
having it return anything, at least without major hackery to
what a statement can do. Of course, we've got the example
of the print statement for that kind of hackery.


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