[Python-Dev] PEP 389: argparse - new command line parsing module

Robert Kern robert.kern at gmail.com
Wed Sep 30 18:58:20 CEST 2009


On 2009-09-30 11:38 AM, Guido van Rossum wrote:
> On a tangent -- a use case that I see happening frequently but which
> is pretty poorly supported by optparse is a command-line that has a
> bunch of general flags, then a 'subcommand name', and then more flags,
> specific to the subcommand. Most here are probably familiar with this
> pattern from SVN, Hg, and other revision control systems (P4 anyone?)
> with a rich command-line interface. There are some variants, e.g.
> whether global and subcommand-specific flags may overlap, and whether
> flags may follow positional args (Hg and SVN seem to differ here a
> bit).
>
> I've helped write at least two tools at Google that have this
> structure; both used different approaches, and neither was
> particularly easy to get right. Getting all the different --help
> output to make sense was mostly a manual process. (E.g. "foo --help"
> should print the general flags and the list of known subcommands,
> whereas "foo --help subcommand" should print flags and other usage
> info about the specific subcommand.) Also switching out to different
> calls based on the subcommand should/might be part of this.
>
> I would be willing to live with a third option parser in the stdlib if
> it solved this problem well.

I don't think argparse supports the "foo --help subcommand" OOB. I think it 
would be simple to modify argparse to make it do so. It does support general 
options followed by a subcommand with options, though.

http://argparse.googlecode.com/svn/tags/r101/doc/other-methods.html#sub-commands

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



More information about the Python-Dev mailing list