paul j3 <ajipa...@gmail.com> added the comment:
While I don't think this change will cause any backward compatibility issues, I wonder whether it does much good. https://docs.python.org/3/library/argparse.html#exiting-methods already documents the option of customizing `parser.exit` and `parser.error` parser.exit has the optional status argument (default 0). I don't see how an error method with optional status can be used without some sort of subclassing. At least not for standard argparse errors. It would only help for custom error calls. parser.error('my own error message', status=0) The usual errors are issued with a self.error(message) call. Unittest, 'test_argparse.py' has a ErrorRaisingArgumentParser class that customizes both error() and exit(). But its error catching code is a bit complicated. Another SO reference on argparse unittesting: https://stackoverflow.com/questions/39028204/using-unittest-to-test-argparse-exit-errors ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34742> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
