This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author paul.j3
Recipients Ankit Goel, paul.j3, xtreak
Date 2018-09-20.17:13:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1537463607.5.0.956365154283.issue34742@psf.upfronthosting.co.za>
In-reply-to
Content
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
History
Date User Action Args
2018-09-20 17:13:27paul.j3setrecipients: + paul.j3, xtreak, Ankit Goel
2018-09-20 17:13:27paul.j3setmessageid: <1537463607.5.0.956365154283.issue34742@psf.upfronthosting.co.za>
2018-09-20 17:13:27paul.j3linkissue34742 messages
2018-09-20 17:13:27paul.j3create