Message325909
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 |
|
Date |
User |
Action |
Args |
2018-09-20 17:13:27 | paul.j3 | set | recipients:
+ paul.j3, xtreak, Ankit Goel |
2018-09-20 17:13:27 | paul.j3 | set | messageid: <1537463607.5.0.956365154283.issue34742@psf.upfronthosting.co.za> |
2018-09-20 17:13:27 | paul.j3 | link | issue34742 messages |
2018-09-20 17:13:27 | paul.j3 | create | |
|