[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