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

Greg Ewing greg.ewing at canterbury.ac.nz
Fri Feb 13 01:33:48 CET 2009

Antoine Pitrou wrote:

> The problem I can see is that in normal iteration forms (e.g. a "for" loop), the
> argument to StopIteration is ignored. Therefore, a generator executing such a
> return statement and expecting the caller to use the return value wouldn't be
> usable in normal iteration contexts.

How is this different from an ordinary function returning a
value that is ignored by the caller?

It's up to the caller to decide whether to use the return
value. If it wants the return value, then it has to either
use a 'yield from' or catch the StopIteration itself and
extract the value.

> There seems to lack at least a "yield" statement in this snippet.

You're right, there should be some yields there. I'll
post a fixed version.

> Also, why doesn't it call iter() first? Does it mean one couldn't write e.g. 
> "yield from my_list"?

I'm not sure about that. Since you can't send anything to a list
iterator, there's not a huge advantage over 'for x in my_list: yield x',
but I suppose it's a logical and useful thing to be able to do.

> Besides, the idea of getting the "result" from the /inner/ generator goes
> against the current semantics of "result = yield value", where the result comes
> from the /outer/ calling routine.

I'm going to add some more material to the Rationale section that
will hopefully make it clearer why I want it to work this way.


More information about the Python-ideas mailing list