[Python-ideas] Yield-From: Finalization guarantees

Greg Ewing greg.ewing at canterbury.ac.nz
Thu Mar 26 07:00:57 CET 2009


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



More information about the Python-ideas mailing list