Exception handling in Python 3.x

[Ethan Furman]

Peter Otten wrote:
> Hrvoje Niksic wrote:
> 
>> Peter Otten <__peter__ at web.de> writes:
>>
>>>> Note that StopIteration is an internal detail of no relevance whatsoever
>>>> to the caller. Expose this is unnecessary at best and confusing at
>>>> worst.
>>> http://mail.python.org/pipermail/python-list/2010-October/1258606.html
>>> http://mail.python.org/pipermail/python-list/2010-October/1259024.html
>> Both of these involve suppressing the chaining at the wrong place,
>> namely in the outer handler or, worse yet, in the exception display
>> mechanism.  Steven, on the other hand, wants his *inner* handler to
>> express that the original exception was an implementation detail, a
>> business exception such as StopIteration, that is completely irrelevant
>> to the actual exception being raised.  The outer handler is the wrong
>> place to suppress the chaining because it has no way of distinguishing
>> Steven's case from a genuine case of a new exception unexpectedly
>> occurring during handling of the original exception.
> 
> To quote the Rolling Stones: You can't always get what you want. 
> 
> After rereading the original post I still don't get why the workarounds 
> provided in those links aren't worth considering.

For me at least it's a matter of simplicity, clarity, and the Way of the 
Python  ;)

The workarounds are boiler-plate for a fairly common situation, and one 
of the things i _love_ about python is the *lack* of boilerplate.

I think the real question is is there any progress on dealing with the 
Open Issue in the PEP?

     Open Issue: Suppressing Context
     As written, this PEP makes it impossible to suppress '__context__',
     since setting exc.__context__ to None in an 'except' or 'finally'
     clause will only result in it being set again when exc is raised.

     http://www.python.org/dev/peps/pep-3134/

~Ethan~