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.
_______________________________________________
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
