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

Greg Ewing greg.ewing at canterbury.ac.nz
Fri Apr 17 06:52:20 CEST 2009

Jacob Holm wrote:

> 1) IIRC, the use of sys.exc_info() is not needed in 3.x as all 
> exceptions have a __traceback__ attribute.

The 3.0 docs still list the signature of throw() as
having 3 args, though, so I'll leave it that way for

> 2) The expansion is not handling StopIterations raised as a result of 
> calling _i.throw().

Yes, I was a bit too aggressive in ripping out
StopIteration handling there. :-)

> A simpler expansion based on 1) and 2) but otherwise identical is:

I had a try block around everything in an earlier
version, but I changed it because it was prone to
catching too much. I think I'll stick with separate
targeted try blocks, because it's easier to make
sure I'm catching only what I intend to catch.

> 3) If the subiterator has a close() but doesn't have throw() it won't be 
> closed when throw() is called on the outer generator.  This is fine with 
> me, I am just not sure if it is intentional.
> 4) If the subiterator has a close() but doesn't have send() it won't be 
> closed when a send() on the outer generator causes an AttributeError in 
> the expansion.  Again this is fine with me, I am just not sure if it is 
> intentional.

I'm not worried about those much. The important thing
is for explicit finalization to work as expected.

> 5) The last paragraph in the "Use of StopIteration to return values" 
> section, seems to be a leftover from an earlier draft of the PEP that 
> used a different exception.

Yes, I need to remove that.

> 6) Several of the issues we have been discussing on python-ideas are not 
> mentioned at all:

I'll add some discussion about these.

> 7) By not mentioning caching, you are effectively saying the methods 
> won't be cached.

That's what I mean to say. Guido has pointed out that
Python doesn't generally do cacheing if it would change
the behaviour of the code, which means we can't do
cacheing here.

There's still a fast path available if the subiterator
is a generator, which is the case I'm mostly concerned
about, so I'm not as worried as I was about not being
able to cache send().


More information about the Python-ideas mailing list