It would be useful if optparse could display version right in usage help 
before command syntax. Right now it can only output either usage or 
version.

Hi, optparse is now deprecated, and argparse is the replacement, so I'm closing this report.

Does argparse display version by default?

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.

On Sat, Mar 26, 2011 at 12:20 PM, Steven Bethard <report@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

On Sat, Mar 26, 2011 at 12:20 PM, Steven Bethard <report@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".

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

On Sat, Mar 26, 2011 at 9:14 PM, anatoly techtonik <techtonik@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.

On Sat, Mar 26, 2011 at 2:28 PM, Steven Bethard <report@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. ;)

I'm moving this over to Issue 11695, which proposes support for a usage/help message template.