<p>The class method approach I describe in the linked issue is more likely to be accepted - this problem shouldn't need new syntax to resolve. </p>
<p>--<br>
Nick Coghlan (via Gmail on Android, so likely to be more terse than usual)</p>
<div class="gmail_quote">On Oct 22, 2011 4:47 PM, "Steven D&#39;Aprano" <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jan Kaliszewski wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello.<br>
<br>
Some time ago I encountered the problem described in PEP 3134 as "Open<br>
Issue: Suppressing Context" ("this PEP makes it impossible to suppress<br>
'__context__', since setting exc.__context__ to None in an 'except' or<br>
'finally' clause will only result in it being set again when exc is<br>
raised.").<br>
<br>
An idea that then appeared in my brain was:<br>
<br>
    raise SomeException(some, arguments) from None<br>
<br>
...and I see the same idea has been proposed by Patrick Westerhoff here:<br>
<a href="http://bugs.python.org/issue6210" target="_blank">http://bugs.python.org/<u></u>issue6210</a><br>
</blockquote>
<br>
<br>
I think that stating the syntax is the easy part, actually implementing may not be so simple.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am +10, as I feel that's intuitive, elegant and status-quo-consistent.<br>
<br>
And what do you think?<br>
</blockquote>
<br>
I think that it's well past time to fix this wart with the new nested exceptions functionality.<br>
<br>
+1<br>
<br>
(Actually I'm also +10 but I don't want to start vote inflation.)<br>
<br>
The wart I'm referring to is that the common idiom of catching one exception and raising another is now treated as a bug in the except clause even when it isn't:<br>
<br>
>>> def mean(data):<br>
...     try:<br>
...             return sum(data)/len(data)<br>
...     except ZeroDivisionError:<br>
...             raise ValueError('data must be non-empty')<br>
...<br>
>>> mean([])<br>
Traceback (most recent call last):<br>
  File "<stdin>", line 3, in mean<br>
ZeroDivisionError: int division or modulo by zero<br>
<br>
During handling of the above exception, another exception occurred:<br>
<br>
Traceback (most recent call last):<br>
  File "<stdin>", line 1, in <module><br>
  File "<stdin>", line 5, in mean<br>
ValueError: data must be non-empty<br>
<br>
<br>
In this case, there is absolutely no reason to expose the fact that ZeroDivisionError occurred. That's an implementation detail which is irrelevant to the caller. But exposing it complicates the traceback for no benefit (since it isn't a bug that needs fixing) and possibly some harm (by causing some confusion to the reader).<br>

<br>
It also reflects badly on your code: it gives the impression of an unhandled bug when it is not.<br>
<br>
In my opinion, although the error context functionality is a big positive when debugging actual bugs in except clauses, the feature should never have been added without a way to suppress the error context.<br>
<br>
<br>
-- <br>
Steven<br>
______________________________<u></u>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/<u></u>mailman/listinfo/python-ideas</a><br>
</blockquote></div>