New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--help for runnable stdlib modules #68832
Comments
Support for python -m<runnable-stdlib-module> [-h|--help] is a bit patchy right now: $ python -mpdb -h
usage: pdb.py [-c command] ... pyfile [arg] ...
<help elided> $ python -mpdb --help
Traceback (most recent call last):
File "/usr/lib/python3.4/runpy.py", line 170, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib/python3.4/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/usr/lib/python3.4/pdb.py", line 1685, in <module>
pdb.main()
File "/usr/lib/python3.4/pdb.py", line 1629, in main
opts, args = getopt.getopt(sys.argv[1:], 'hc:', ['--help', '--command='])
File "/usr/lib/python3.4/getopt.py", line 93, in getopt
opts, args = do_longs(opts, args[0][2:], longopts, args[1:])
File "/usr/lib/python3.4/getopt.py", line 157, in do_longs
has_arg, opt = long_has_args(opt, longopts)
File "/usr/lib/python3.4/getopt.py", line 174, in long_has_args
raise GetoptError(_('option --%s not recognized') % opt, opt)
getopt.GetoptError: option --help not recognized
# <-- not a getopt specialist but --help is actually listed in the call to getopt! $ python -mtrace -h
/usr/lib/python3.4/trace.py: option -h not recognized
Try `/usr/lib/python3.4/trace.py --help' for more information
$ python -mtrace --help
Usage: /usr/lib/python3.4/trace.py [OPTIONS] <file> [ARGS]
<help elided> |
Please open individual issues to address individual modules that you would like to contribute to improving. Adding/fixing help is often best done by rewriting the argument parsing...contributions have been made to improve several modules already. In most cases we don't have tests for the -m features, and those need to be created first. In some cases we don't really want to continue to support whatever -m code exists (because it exists for no-longer-relevant historical reasons...though that doesn't apply in the two cases you reference). So each module needs to be addressed individually. To address the specific issue you raise: I believe that when we have rewritten things, we have chosen to follow argparse's lead and support both -h and --help for the display of help information. |
To be honest I don't really plan to contribute any patch on this specific issue right now, the CLI interface of e.g. trace has some other serious issues (see e.g. bpo-24649) that I don't want to work out, and writing tests for the CLI are a pain too (also why I haven't made more progress on bpo-23596). |
Yes, that's pretty much why things are in the state they are in ;) Still, opening individual issues for help problems with individual modules is the way to go, as you did (thank you). |
It shouldn't be particularly difficult to do it using script_helper.assert_python_{ok|failure}(), even though you could also check the argument /parsing/ separately without having to launch a subprocess. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: