On Wed, Apr 1, 2009 at 4:28 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
You appear to be thinking of GeneratorExit as a way to ask a generator to finish normally such that it still makes sense to try to return a value after a GeneratorExit has been thrown in to the current frame, but that really isn't its role.
Instead, it's more of an "Abandon Ship! Abandon Ship! All hands to the lifeboats!" indication that gives the generator a chance to release any resources it might be holding and bail out. The reason that close() accepts a StopIteration as well as a GeneratorExit is that the former still indicates that the generator has finalised itself, so the objective of calling close() has been achieved and there is no need to report an error.
Any code that catches GeneratorExit without reraising it is highly suspect, just like code that suppresses SystemExit and KeyboardInterrupt.
Let's make that "without either returning from the generator without yielding any more values, raising StopIteration, or re-raising GeneratorExit." At least one example in PEP 342 catches GeneratorExit and returns. -- --Guido van Rossum (home page: http://www.python.org/~guido/)