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).
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
