[Python-ideas] Revised**10 PEP on Yield-From

Greg Ewing greg.ewing at canterbury.ac.nz
Thu Apr 16 04:35:02 CEST 2009


Erik Groeneveld wrote:

> By "closing the delegating generator" you mean "from the outside, call
> close() on it"?

Yes, that's right.

> I assume that 'return 1 2 3' will have one return value being a tuple
> (1,2,3)

Um, you can't write 'return 1 2 3'. You can write
'return 1, 2, 3' which returns a tuple.

>> For convenience, the ``StopIteration`` exception will be given a
>> ``value`` attribute that holds its first argument, or None if there
>> are no arguments.
> 
> I am using StopIteration's 'args' atrribute?

The 'value' attribute is purely a convenience -- you
can get it from args[0] just as well.

> For clearity, you could probably add the name of the refactoring, it
> is called 'extract method' isn't it?

Quite likely it's called that in some book or other,
I wouldn't really know. I don't think of refactorings
as having names, I just do them.

> Yes, I believe you make sure that:
> 
> try:
>     x = yield from y()
> except SomeError:
>    return 'HELP'
> 
> actually does catch the SomeError exception when raised in y(), or one
> it its descendants?

That's the idea.

>> Originally it was proposed to simply extend StopIteration to accept
>> a value...

That whole paragraph shouldn't be there, it's left over
from an earlier version. Guido originally wanted to use
a different exception for returning with a value, but
he changed his mind.

> Will the the delegating generator remain on the call-stack or not?

It certainly shows up in tracebacks, but I'm not
actually sure whether it will be seen by
sys._getframe() while a subiterator is running
in my current implementation. I'll try an
experiment to find out.

Even if it does, it's probably not something you
should rely on, since a different implementation
that optimizes more aggressively could behave
differently.

In the case of thread-local storage for generator
based threads, I don't think I would try to attach
them to a generator frame, because a thread isn't
just a single generator, it's a collection of
generators.

Rather I'd use the scheduler to manage them. The
scheduler knows when it's switching from one
thread to another and can switch in the appropriate
set of variables.

-- 
Greg



More information about the Python-ideas mailing list