Message335059
The proposed PR does not address this issue. It just adds comments to the method code, which aren't really needed. The method is short and obvious. We don't need, at this time, to get into questions of whether comments in argparse.py conform to one of the PEPs.
All this issue needs is a change to the documentation. Changing:
ArgumentParser.exit(status=0, message=None)
This method terminates the program, exiting with the specified status and, if given, it prints a message before that.
to:
ArgumentParser.exit(status=0, message=None)
This method terminates the program, exiting with the specified status and, if given, it prints a message to **standard error** before that.
While I'm not opposed to this change, I don't think it is important.
The documentation makes these two methods public, which I believe serves two purposes:
- developers may want to issue their own `parser.error('...')` call, during post-parsing value checking, or issue their own `parser.exit()` call in a custom 'Action' class (much like what '_HelpAction' does).
- developers might want to modify one or both of these in a ArgumentParser subclass. The unittesting code in argparse does this to capture and redirect errors.
In both cases I expect the developer will want to read the code as well as the documentation. The fact that `exit()` uses stderr is quite obvious from the code.
It's worth keeping in mind that the documentation never replicates the code. For example, in this case the documentation says error(), "terminates the program with a status code of 2.", when what it really does is "terminates with a call to exit(status=2)". |
|
Date |
User |
Action |
Args |
2019-02-08 05:44:02 | paul.j3 | set | recipients:
+ paul.j3, bethard, docs@python, philiprowlands, vinayb21 |
2019-02-08 05:44:01 | paul.j3 | set | messageid: <1549604641.66.0.083032739241.issue35533@roundup.psfhosted.org> |
2019-02-08 05:44:01 | paul.j3 | link | issue35533 messages |
2019-02-08 05:44:01 | paul.j3 | create | |
|