[issue3079] sys.exit() called from optparse - bad, bad, bad
Phillip M. Feldman pfeld...@verizon.net added the comment: The current behavior of optparse is contrary to how most of Python works. optparse should throw a named exception that can be trapped and identified by the calling program. Doing a SystemExit is unacceptable. I can't believe that this is such a hard thing to fix. -- nosy: +pfeld...@verizon.net ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3079] sys.exit() called from optparse - bad, bad, bad
R. David Murray rdmur...@bitdance.com added the comment: There was recently a long discussion of this on python-dev (in the context of a proposal to add argparse to the stdlib; argparse does the same thing). The conclusion was that the current behavior is the most useful behavior, and that if you don't want to exit you can either subclass or catch SystemExit. -- nosy: +r.david.murray resolution: - wont fix stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3079] sys.exit() called from optparse - bad, bad, bad
Phillip M. Feldman pfeld...@verizon.net added the comment: Thanks for the response! I can indeed catch SystemExit, but I would like to be able to take one action (terminate the program) if the user supplied an unknown option, and another action (prompt for a new value) if the user supplied a bad value for an option. I suspect that I can achieve this by subclassing, but I'm not yet at that level of Python sophistication. Yours, Phillip R. David Murray wrote: R. David Murray rdmur...@bitdance.com added the comment: There was recently a long discussion of this on python-dev (in the context of a proposal to add argparse to the stdlib; argparse does the same thing). The conclusion was that the current behavior is the most useful behavior, and that if you don't want to exit you can either subclass or catch SystemExit. -- nosy: +r.david.murray resolution: - wont fix stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3079 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3079] sys.exit() called from optparse - bad, bad, bad
Antoine Pitrou [EMAIL PROTECTED] added the comment: The current behaviour is useful in that most of time, it is convenient to let OptionParser display a standard error message and bail out. However, having an attribute on the OptionParser object (e.g. exit_on_errors) to be able to change this behaviour is a reasonable proposition. -- nosy: +pitrou ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3079] sys.exit() called from optparse - bad, bad, bad
Georg Brandl [EMAIL PROTECTED] added the comment: I agree with Antoine that the standard behavior is what you want in most simple command-line scripts. It's easy enough to replace the parser's exit function to just print the message, or raise an exception. -- nosy: +georg.brandl ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3079] sys.exit() called from optparse - bad, bad, bad
Skip Montanaro [EMAIL PROTECTED] added the comment: Georg I agree with Antoine that the standard behavior is what you want in most Georg simple command-line scripts. Georg It's easy enough to replace the parser's exit function to just print the Georg message, or raise an exception. Check the code. Most of the time error is called without an exception having been raised. In one case it actually is called and swallows an exception that the code did raise. It would be preferable in my mind to always raise an exception. If you want, the default can be to catch them and ignore them as error() does now, but as it stands you can't raise anything more specific than OptParseError, and that's just a punt even though specific problems were detected by the code. Skip ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3079] sys.exit() called from optparse - bad, bad, bad
Changes by Gabriel Genellina [EMAIL PROTECTED]: -- nosy: +gagenellina ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3079] sys.exit() called from optparse - bad, bad, bad
New submission from Skip Montanaro [EMAIL PROTECTED]: This seems like a bug in optparse.OptionParser: def exit(self, status=0, msg=None): if msg: sys.stderr.write(msg) sys.exit(status) def error(self, msg): error(msg : string) Print a usage message incorporating 'msg' to stderr and exit. If you override this in a subclass, it should not return -- it should either exit or raise an exception. self.print_usage(sys.stderr) self.exit(2, %s: error: %s\n % (self.get_prog_name(), msg)) By default I think it should raise an exception when it encounters an error, not exit. Programmers shouldn't be forced to subclass code in the standard library to get recommended practice. If you feel this behavior can't be changed in 2.6 it should at least be corrected in 3.0. The cruel irony is that inside OptionParser.parse_args it actually catches both BadOptionError and OptionValueError but suppresses them by calling self.error() within the except block... *arrhhh*... The correct behavior there is (in my opinion) to get rid of the try/except statement altogether and just let the exceptions propagate. Other calls to self.error() should be replaced with suitable raise statements. Skip -- components: Library (Lib) keywords: easy messages: 67999 nosy: skip.montanaro priority: normal severity: normal status: open title: sys.exit() called from optparse - bad, bad, bad type: behavior versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3079] sys.exit() called from optparse - bad, bad, bad
Changes by Skip Montanaro [EMAIL PROTECTED]: -- versions: +Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
