[Python-Dev] GeneratorExit inheriting from Exception

Nick Coghlan ncoghlan at gmail.com
Sat Mar 25 19:04:23 CET 2006


Guido van Rossum wrote:
> On 3/25/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> OTOH, if GeneratorExit inherits from Exception (as in current SVN), then two
>> things will be needed to make the generator work correctly:
>>
>> 1. add a preceding exception clause to fix Python 2.5 behaviour:
>>    except GeneratorExit:
>>        raise
>>    except Exception:
>>        # whatever
>>
>> 2. add header code to the module to make it work again on Python 2.4:
>>
>>    try:
>>        GeneratorExit
>>    except NameError:
>>        class GeneratorExit(Exception): pass
>>
>> IMO, that would be an ugly bit of backwards incompatibility (even though I
>> wouldn't expect such broad exception handling in generators to be at all common).
> 
> I can't see all that much use for GeneratorExit in code that needs to
> be compatible with 2.4, since the rest of the machinery that makes
> exception handling around yield feasible doesn't exist.

I agree entirely - my goal is to make sure it stays that way.

The kind of code I'm talking about would be an *existing* Python 2.4 generator 
that happens to do something like:

   def gen(tasks):
       """yield the results of a bunch of task functions"""
       for task in tasks:
           try:
               yield (task, task())
           except Exception, ex:
               yield ExceptionOccurred(task, ex)


If you run such a generator on Python 2.5, but don't run it to completion 
before it is garbage collected, you will get an error message printed on 
stderr saying that an exception was ignored when this generator was cleaned 
up. If you use the new PEP 342 features to try to explicitly close it before 
it is garbage collected, you'll get the exception directly.

The culprit is the RuntimeError raised when the generator's close() method 
gets upset because the generator swallowed GeneratorExit.

If GeneratorExit inherits directly from BaseException, such unexpected 
behaviour won't happen - the only way for an existing generator to break is if 
it contained a bare except clause, and that code was *already* dubious (e.g. 
it probably swallowed KeyboardInterrupt).

I don't have any actual live examples of a generator with a broad exception 
clause like the one above, but toy generators like the one above are legal in 
2.4 and result in spurious errors with current SVN.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org


More information about the Python-Dev mailing list