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. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------