Peter Otten wrote:
Hrvoje Niksic wrote:
Peter Otten <__pete...@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~
--
http://mail.python.org/mailman/listinfo/python-list
