Nick Coghlan wrote:
I like it because the rules are simple: either an exception is thrown in and passed down to the subiterator (which may have the effect of finalising it), or else the subiterator is left alone (to be finalised either explicitly or implicitly when it is deleted).
Okay, so you're in favour of accepting the risk of prematurely finalizing shared subiterators, on the grounds that it can be prevented using a wrapper in the rare cases where it matters. I can live with that, and in fact it's more or less where my most recent thinking has been leading me.
I like it because the rules are simple: either an exception is thrown in and passed down to the subiterator (which may have the effect of finalising it), or else the subiterator is left alone (to be finalised either explicitly or implicitly when it is deleted).
We might still want one special case. If GeneratorExit is thrown and the subiterator has no throw() or the GeneratorExit propagates back out of the throw(), I think an attempt should be made to close() it. Otherwise, explicitly closing the delegating generator wouldn't be guaranteed to finalize the subiterator unless it had a throw() method, whereas one would expect having close() to be sufficient for this. -- Greg