[Python-3000] self-contained exceptions

Phillip J. Eby pje at telecommunity.com
Mon Jan 8 18:48:28 CET 2007


At 11:34 AM 1/8/2007 -0600, Collin Winter wrote:
>On 1/8/07, Phillip J. Eby <pje at telecommunity.com> wrote:
>>At 10:25 AM 1/8/2007 -0600, Collin Winter wrote:
>> >On 1/8/07, Phillip J. Eby <pje at telecommunity.com> wrote:
>> >>At 09:14 PM 1/7/2007 -0600, Collin Winter wrote:
>> >> >The transformation is as Phillip outlined above, with extra logic to
>> >> >handle the case where e is a tuple or list.
>> >>
>> >>In the tuple or list case, there's no need to reset the variables, because
>> >>then the traceback won't be present any more; the exception object will
>> >>have been discarded after unpacking.
>> >
>> >Ah, good point. I'll update the patch to strip out that extra code.
>>
>>Hm... what happens with things like:
>>
>>       except Exception, x[y]:
>>
>>and
>>
>>       except Exception, x(y).z:
>>
>>Are these currently allowed?  Should they be allowed?  And should we clear
>>them?
>
>They are currently allowed, and they are currently being cleared.

Which is a bit weird, in that x(y).z isn't necessarily even reachable from 
the frame, although x[y] certainly is.  However, there are no guarantees 
that these targets will still be valid at the time of clearing, either, or 
that they allow delattr/delitem to work, so this really sinks the whole 
clearing idea, unless we move to an 'as name' format.  I seem to recall 
that Guido wanted to move to an 'as' clause for Py3K anyway, to avoid the 
"except FooExc, BarExc:" anti-pattern.  So now seems as good a time "as" 
any.  :)



More information about the Python-3000 mailing list