You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Exceptions and arguments disappear when using argparse inside with statement #68258
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2015-04-28.18:29:16.040>created_at=<Date2015-04-28.17:57:25.650>labels= ['type-bug', 'library']
title='Exceptions and arguments disappear when using argparse inside with statement'updated_at=<Date2015-05-06.17:52:11.294>user='https://bugs.python.org/invisibleroads'
Exceptions and arguments disappear when using argparse inside a "with" statement. The behavior was confusing and frustrating because I could not pinpoint why certain arguments were missing or unrecognized.
Unhandled exceptions inside the with statement typically trigger a traceback, unless __exit__ returns True, in which the exception is "swallowed" (https://www.python.org/dev/peps/pep-0343/).
I'm not sure why this is so surprising. parse_args in __exit__ raises a SystmExit, which the Python interpreter takes to mean the program is responsibly exiting. I don't think any other behavior would be reasonable. e.g. sys.exit() in an except clause shouldn't cause the exception to be printed.
The behavior may not be surprising from a technical perspective, but it is unintuitive.
I think exceptions inside a with statement should trigger a traceback, unless you are saying that it is the responsibility of the author to catch and raise the exception inside __exit__, which feels to me like a workaround that is specific to parse_args.
What is happening here is that the __exit__ method gets passed the exception, and then instead of returning and allowing the exception to propagate and be printed, it raises SystemExit (via parse_args), which causes Python to immediately shut down, *before* __exit__ returns and the exception is propagated.
So yes, you'd have to do something specific for argparse (which raises a SystemExit exception if parsing fails) if you want to do something non-normal with SystemExit. That is, you'll need to catch SystemExit.
Activity
invisibleroads commentedon Apr 28, 2015
Exceptions and arguments disappear when using argparse inside a "with" statement. The behavior was confusing and frustrating because I could not pinpoint why certain arguments were missing or unrecognized.
Unhandled exceptions inside the with statement typically trigger a traceback, unless __exit__ returns True, in which the exception is "swallowed" (https://www.python.org/dev/peps/pep-0343/).
However, the NameError exception and tile_indices argument disappear because of a premature sys.exit (https://hg.python.org/cpython/file/default/Lib/argparse.py#l2385).
benjaminp commentedon Apr 28, 2015
I'm not sure why this is so surprising. parse_args in __exit__ raises a SystmExit, which the Python interpreter takes to mean the program is responsibly exiting. I don't think any other behavior would be reasonable. e.g. sys.exit() in an except clause shouldn't cause the exception to be printed.
invisibleroads commentedon May 6, 2015
The behavior may not be surprising from a technical perspective, but it is unintuitive.
I think exceptions inside a with statement should trigger a traceback, unless you are saying that it is the responsibility of the author to catch and raise the exception inside __exit__, which feels to me like a workaround that is specific to parse_args.
bitdancer commentedon May 6, 2015
What is happening here is that the __exit__ method gets passed the exception, and then instead of returning and allowing the exception to propagate and be printed, it raises SystemExit (via parse_args), which causes Python to immediately shut down, *before* __exit__ returns and the exception is propagated.
So yes, you'd have to do something specific for argparse (which raises a SystemExit exception if parsing fails) if you want to do something non-normal with SystemExit. That is, you'll need to catch SystemExit.
This is really a duplicate of bpo-9938.