[Python-ideas] Proto-PEP on a 'yield from' statement

Bruce Frederiksen dangyogi at gmail.com
Fri Feb 13 20:11:42 CET 2009

Greg Ewing wrote:
> Bruce Frederiksen wrote:
>> I'm also against using return as the syntax for a final value from 
>> the subgenerator.
> Can you look at what I said in the last revision about
> "Generators as Threads" and tell me whether you still
> feel that way?
I don't really understand the "Generators as Threads".  You say that a 
function, such as:

y = f(x)

could be translated into "an equivalent" generator call:

y = yield from g(x)

But the yield from form causes g(x) to send output to the caller, which 
f(x) doesn't do.  It seems like I would either want one or the other: 
either yield from g(x) to send g's output to my caller, or y = sum(g(x)) 
to get a final answer myself of the generated values from g(x).

On the other hand, if you're thinking that g(x) is going to be taking 
values from my caller (passed on to it through send) and producing a 
final answer, then we have a problem because g(x) will be using a yield 
expression to accept the values, but the yield expression also produces 
results which will be sent back to my caller.  These results going back 
is probably not what I want.  This is why I think that it's important to 
separate the aspects of sending and receiving values to/from 
generators.  That's why I proposed receive, rather than the yield 
expression, to accept values in the generator.  I would propose 
deprecating the yield expression.  I would also propose changing send to 
only send a value into the generator and not return a result.  Then you 
could get a sum of your input values by:

y = sum(receive)

without generating bogus values back to your caller.

I don't know if this helps, or if I've completely missed the point that 
you were trying to make? ...

-bruce frederiksen

More information about the Python-ideas mailing list