[Python-Dev] PEP 380 (yield from a subgenerator) comments
P.J. Eby
pje at telecommunity.com
Sun Mar 22 01:52:10 CET 2009
At 10:21 AM 3/22/2009 +1200, Greg Ewing wrote:
>P.J. Eby wrote:
>
>>My concern is that allowing 'return value' in generators is going
>>to be confusing, since it effectively causes the return value to
>>"disappear" if you're not using it in this special way with some
>>framework that takes advantage.
>
>But part of all this is that you *don't* need a special
>framework to get the return value -- all you need is a
>caller that uses a yield-from statement. There are uses
>for that besides threading systems.
Such as? I've been wracking my brain trying to come up with any
*other* occasion where I'd need -- or even find it useful -- to have
one generator yield the contents of another generator to its caller,
and then use a separate return value in itself. (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.)
In any case, you didn't address the confusion issue: the inability of
generators to return a value is there for a good reason, and adding a
return value that doesn't actually return anywhere unless you use it
in a yield-from expression -- an expression that both looks like a
statement and has control-flow side-effects -- seems both
over-complex and an invitation to confusion.
This is different from plain yield expressions, in that plain yield
expressions are *symmetric*: the value returned from the yield
expression comes from the place where control flow is passed by the
yield. That is, 'x = yield y' takes value y, passes control flow to
the caller, and then returns a result from the caller. It's like an
inverse function call. 'x = yield from y', on the other hand, first
passes control to y, then the caller, then y, then the caller, an
arbitrary number of times, and then finally returns a value from y,
not the caller.
This is an awful lot of difference in control flow for only a slight
change in syntax -- much more of a difference than the difference
between yield statements and yield expressions.
So at present (for whatever those opinions are worth), I'd say -0 on
a yield-from *statement* (somewhat useful but maybe not worth
bothering with), +0 on a reference trampoline in the stdlib (slightly
better than doing nothing at all, but not by much), and -1 on
yield-from expressions and return values (confusing complication with
very narrowly focused benefit, reasonably doable with library code).
More information about the Python-Dev
mailing list