[issue7284] argparse - display version in usage by default
Steven Bethard steven.beth...@gmail.com added the comment: I'm moving this over to Issue 11695, which proposes support for a usage/help message template. -- resolution: - duplicate stage: - committed/rejected status: open - closed superseder: - Improve argparse usage/help customization ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7284 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7284] argparse - display version in usage by default
Steven Bethard steven.beth...@gmail.com added the comment:
In argparse, you could so something like:
version = 2.7
parser = argparse.ArgumentParser(
description=My program XXX, version + version)
parser.add_argument('-v', action='version', version=version)
That would then produce:
usage: PROG [-h] [-v]
My program XXX, version 2.7
optional arguments:
-h, --help show this help message and exit
-v show program's version number and exit
Is that acceptable? This is basically the style of svn:
$ svn help
usage: svn subcommand [options] [args]
Subversion command-line client, version 1.6.15.
...
I see though that vi puts the full name and version before the usage (which is
currently impossible in argparse):
$ vi --help
VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 19 2009 17:22:08)
usage: vim [arguments] [file ..] edit specified file(s)
...
Most other programs I tried didn't give a version number at all, though some
did give a full name before the usage:
$ hg
Mercurial Distributed SCM
...
$ hg clone --help
hg clone [OPTION]... SOURCE [DEST]
...
$ git
usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]
...
$ emacs --help
Usage: emacs [OPTION-OR-FILENAME]...
...
I guess we could add, say, a headline= option to ArgumentParser which would
then be printed before the usage message if it's really crucial to have that
message first... I'd rather not though if the description= approach is
acceptable to you, since adding headline= would add more complexity to an
already complex ArgumentParser constructor.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7284
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7284] argparse - display version in usage by default
anatoly techtonik techto...@gmail.com added the comment: On Sat, Mar 26, 2011 at 12:20 PM, Steven Bethard rep...@bugs.python.org wrote: I see though that vi puts the full name and version before the usage (which is currently impossible in argparse): That was exactly my use case, which I'd say is very common for small utilities. Just in 10 minutes I could find that about a half of command line utilities on my Windows machine are reporting full name and version before the usage with --help option, including NSIS, PuTTY, Far Manager, Android Debug Bridge and 7-Zip. A pity that before argparse replaced optparse, there was no research made to gather the output from various console tools to see how argparse really saves people from reinventing their solutions. Do you think we could avoid this problem if there was more active turnaround between Roundup community and Python community to import all issues from Google Code tracker in time to do some planning? http://code.google.com/p/argparse/issues/detail?id=50 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7284 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7284] argparse - display version in usage by default
anatoly techtonik techto...@gmail.com added the comment: On Sat, Mar 26, 2011 at 12:20 PM, Steven Bethard rep...@bugs.python.org wrote: I guess we could add, say, a headline= option to ArgumentParser which would then be printed before the usage message if it's really crucial to have that message first... I'd rather not though if the description= approach is acceptable to you, since adding headline= would add more complexity to an already complex ArgumentParser constructor. Instead of adding epilog, usage, description to constructor, you could just add one usage_template with these substitution variables, including version. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7284 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7284] argparse - display version in usage by default
Steven Bethard steven.beth...@gmail.com added the comment: I'm not sure about the usage_template approach - seems like it might be hard to make it work, while still supporting formatter_class. (Though maybe it's not so bad since the formatter class methods are all considered implementation details.) I'm open to patches though if you're willing to provide one. In the meantime, a simple approach that will work is to override format_help(): class MyArgumentParser(argparse.ArgumentParser): def format_help(self): help = super(MyArgumentParser, self).format_help() return headline + '\n' + help -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7284 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7284] argparse - display version in usage by default
Nick Coghlan ncogh...@gmail.com added the comment: On Sat, Mar 26, 2011 at 9:14 PM, anatoly techtonik techto...@gmail.com wrote: A pity that before argparse replaced optparse, there was no research made to gather the output from various console tools to see how argparse really saves people from reinventing their solutions. argparse was adopted because it was a significant improvement over optparse, not because anyone was under the illusion that it was perfect. There'll always be room for additional feature requests, and many of them won't cause backwards compatibility problems. Cheers, Nick. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7284 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7284] argparse - display version in usage by default
anatoly techtonik techto...@gmail.com added the comment: On Sat, Mar 26, 2011 at 2:28 PM, Steven Bethard rep...@bugs.python.org wrote: I'm not sure about the usage_template approach - seems like it might be hard to make it work, while still supporting formatter_class. (Though maybe it's not so bad since the formatter class methods are all considered implementation details.) I'm open to patches though if you're willing to provide one. The main point was to cut extra arguments in constructor that are used solely for formatting the result, but it is too late to do any changes now. In the meantime, a simple approach that will work is to override format_help(): class MyArgumentParser(argparse.ArgumentParser): def format_help(self): help = super(MyArgumentParser, self).format_help() return headline + '\n' + help Thanks. I'll try this one next time or think about the patch. ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7284 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7284] argparse - display version in usage by default
Changes by Éric Araujo mer...@netwok.org: -- nosy: +bethard -aronacher resolution: wont fix - stage: committed/rejected - title: optparse - display version in usage by default - argparse - display version in usage by default ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7284 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
