[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

AltStyle によって変換されたページ (->オリジナル) /