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 now.
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(). -- Greg