[Python-ideas] Yield-From: Finalization guarantees

Nick Coghlan ncoghlan at gmail.com
Fri Mar 27 11:51:37 CET 2009

Greg Ewing wrote:
> Nick Coghlan wrote:
>> That makes perfect sense to me as a justification for treating
>> GeneratorExit the same as any other exception (i.e. delegating it to the
>> subgenerator). It doesn't lead me to think that the semantics ever need
>> to involve calling close().
> I'm also treating close() and throw(GeneratorExit) on
> the delegating generator as equivalent for finalization
> purposes. So if throw(GeneratorExit) doesn't fall back
> to close() on the subiterator, closing the delegating
> generator won't finalize the subiterator unless it
> pretends to be a generator by implementing throw().
> Since the inlining principle strictly only applies to
> subgenerators, it doesn't *require* this behaviour,
> but to my mind it strongly suggests it.

I believe I already said this at some point, but after realising that
shareable subiterators are almost still going to be better handled by
iterating over them rather than delegating to them, I'm actually not too
worried one way or the other.

While I do still have a slight preference for limiting the methods
involved in generator delegation to just next(), send() and throw(), I
won't object strenuously to accepting close() as an alternative spelling
of throw(exc) that will always reraise the passed in exception.

As you say, it does make it easier to write a non-generator delegation
target, since implementing close() for finalisation means not having to
deal with the vagaries of correctly reraising exceptions.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-ideas mailing list