[Python-Dev] PEP 380 (yield from a subgenerator) comments

[P.J. Eby]

At 08:11 PM 3/22/2009 +1200, Greg Ewing wrote:
>P.J. Eby wrote:
>
>>(I'm thus finding it hard to believe there's a non-contrived 
>>example that's not doing I/O, scheduling, or some other form of 
>>co-operative multitasking.)
>
>Have you seen my xml parser example?
>
>http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/
>
>Whether you'll consider it contrived or not I don't know
>(contrivedness being such a subjective property) but it
>illustrates the style of programming I'm trying to support
>with the return-value feature.

I find the parser *without* yield-from to be much easier to follow 
what's going on, actually...  and don't see what benefit was obtained 
by the additional complication of using send().


>>In any case, you didn't address the confusion issue: the inability 
>>of generators to return a value is there for a good reason,
>
>It's there because formerly there was nowhere for the
>return value to go. If there is somewhere for it to go,
>the restriction will no longer be needed.

But that's begging the question (in the original meaning of the 
phrase) of why we *want* to have two ways to return data from a generator.


>As for confusion, we ignore the return values of function
>calls all the time, without worrying that someone might be
>confused by the fact that their return value doesn't go
>anywhere. And that's the right way to think of a yield-from
>expression -- as a kind of function call, not a kind of yield.

But it's not a function call -- it's multiple *inverted* function 
calls, followed by special handling of the last iteration of the 
iterator it takes.

The control flow is also hard to explain, as is the implementation.


>If there's anything confusing, it's the presence of the
>word 'yield'. Its only virtue is that it gives a clue that
>the construct has something to do with generators, but
>you'll have to RTM to find out exactly what. Nobody has
>thus far suggested any better name, however.

Perhaps this is because it's not that interesting of a feature.  As I 
said, I wouldn't fight a yield-from statement without all this 
return-value stuff, although it still seems like too much trouble to me.