[Python-ideas] Proto-PEP on a 'yield from' statement
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? ...
More information about the Python-ideas