Title: Command-line option to suppress "from None" for debugging
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.8
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Mariatta, ethan.furman, martin.panter, ncoghlan, rhettinger, serhiy.storchaka, wolma
Priority: normal Keywords:

Created on 2017-04-18 22:11 by rhettinger, last changed 2020-02-29 23:13 by vstinner.

Messages (6)
msg291844 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-04-18 22:11
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".   Where the "-C" option means "Always show the cause of exceptions even when 'from None' is present.
msg291857 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-04-19 04:06
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.
msg293185 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2017-05-07 09:29
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/", line 699, in __delitem__
    raise KeyError(key) from None

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/", line 688, in __setitem__
    value = self.encodevalue(value)
  File "/usr/lib/python3.5/", 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>
msg293466 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-05-11 00:35
See also my old PEP 490 -- Chain exceptions at C level, more or less abandonned :-p
msg362476 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2020-02-22 20:13
+1 for the idea.

Instead of '-C' we could add it as one of the '-X' options -- it is, after all, a development issue.
msg362485 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2020-02-23 00:14
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.
Date User Action Args
2020-02-29 23:13:57vstinnersetnosy: - vstinner
2020-02-23 00:14:55ethan.furmansetmessages: + msg362485
2020-02-22 20:13:27ethan.furmansetnosy: + ethan.furman
messages: + msg362476
2018-01-29 20:48:15rhettingersetversions: + Python 3.8, - Python 3.7
2017-05-11 00:35:31vstinnersetnosy: + vstinner, ncoghlan
messages: + msg293466
2017-05-07 09:29:04martin.pantersetnosy: + martin.panter
messages: + msg293185
2017-04-20 10:20:54wolmasetnosy: + wolma
2017-04-19 04:39:15Mariattasetnosy: + Mariatta
2017-04-19 04:06:52serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg291857
2017-04-18 22:11:52rhettingercreate