Filing this feature request on behalf of an engineering team that I work with.

This team creates Python tools for use by other departments.  Accordingly, their best practice is to use "raise CleanException from None" to give the cleanest error messages to their users while hiding the noise of implementation details and internal logic.  The exposed exceptions are a documented, guaranteed part of the API that users can reliably catch and handle.  This has worked well for them; however, when they are debugging the library itself it would be nice to have a way to suppress all the "from None" code and see fuller stack traces that indicate root causes.

One way to do this would be to have a command-line switch such as "python -C testcode.py".   Where the "-C" option means "Always show the cause of exceptions even when 'from None' is present.

The initial exception still is linked as __context__. You can write own implementation of traceback.print_exception() that ignores __suppress_context__. Alternatively you can just set __suppress_context__ to False.

This proposal would be useful. My use case is for when an API suppresses an external exception context:

>>> import os
>>> try:
...     os.environ["NEW_VARIABLE"] = bug  # Hidden exception
... finally:
...     del os.environ["NEW_VARIABLE"]  # KeyError
... 
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File "/usr/lib/python3.5/os.py", line 699, in __delitem__
    raise KeyError(key) from None
KeyError: 'NEW_VARIABLE'

This feels like a step backwards to Python 2, and enabling the full backtrace would make this easier to analyze:

>>> try:
...     os.environ["NEW_VARIABLE"] = bug  # TypeError
... finally:
...     del dict()["NEW_VARIABLE"]  # KeyError
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/usr/lib/python3.5/os.py", line 688, in __setitem__
    value = self.encodevalue(value)
  File "/usr/lib/python3.5/os.py", line 756, in encode
    raise TypeError("str expected, not %s" % type(value).__name__)
TypeError: str expected, not object

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
KeyError: 'NEW_VARIABLE'

See also my old PEP 490 -- Chain exceptions at C level, more or less abandonned :-p

+1 for the idea.

Instead of '-C' we could add it as one of the '-X' options -- it is, after all, a development issue.

The actual problem, I think, is that `from None` is suppressing more than it ought.  Martin's example would work just fine if the only omitted exception was the one captured during its own try/except.

Created issue39725.