paul j3 <ajipa...@gmail.com> added the comment:
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)".
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35533>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
