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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4