I started to learn Python, and now I\'m learning the great benefits of argparse
.
Using argparse
, I have created two groups of arguments: group_li
A simpler version of this parser is
parser=argparse.ArgumentParser(description="this is the description",
epilog='this is the epilog')
parser.add_argument('-v', '--vebose', action='count')
g1=parser.add_mutually_exclusive_group()
g1.add_argument('--list', help='list module or ports (default=%(default)s)', choices=['modules','ports','all'], default='all')
g1.add_argument('--simulate', '-M','-P','-C', help='simulate [module down/ FS port down/ iSCSI port down]', dest='simulate', metavar='module/port')
With a help that looks like:
usage: stack14660876.py [-h] [-v]
[--list {modules,ports,all} | --simulate module/port]
this is the description
optional arguments:
-h, --help show this help message and exit
-v, --vebose
--list {modules,ports,all}
list module or ports (default=all)
--simulate module/port, -M module/port, -P module/port, -C module/port
simulate [module down/ FS port down/ iSCSI port down]
this is the epilog
Beside verbose
(here I substituted a count
) the OP sets to attributes, list
and simulate
. list
has a default value of all
, and can be set to modules
or ports
. -m
and -p
are just short cuts, and don't really add to the definition. Shortcuts can be handy when defining lots of options, especially if the options can be used together (e.g. -vpm
). But here only one option is allowed (besides -v
).
simulate
takes an unconstrained string. The M/P/C
options are just documentation conveniences, and don't constrain the values or add meaning.
This is a nice exercise in pushing the boundaries of argparse
(or any other parser), but I think it is too complicated to be useful. Despite all the groupings it comes down to allowing only one option.
==========================
Comments about docopt
and POSIX
argument handling prompted me to look at C argument libraries. getopt
is the old standard. Python has a functional equivalent, https://docs.python.org/2/library/getopt.html
The other parser in the GNU library is argp
.
http://www.gnu.org/software/libc/manual/html_node/Argp.html
I haven't seen, yet, a clear description of what it adds to the getopt
syntax. But the following paragraph is interesting.
Argp also provides the ability to merge several independently defined option parsers into one, mediating conflicts between them and making the result appear seamless. A library can export an argp option parser that user programs might employ in conjunction with their own option parsers, resulting in less work for the user programs. Some programs may use only argument parsers exported by libraries, thereby achieving consistent and efficient option-parsing for abstractions implemented by the libraries.
It sounds a bit like the argparse
subparser mechanism. That is, there's some sort of meta-parser that can delegate the action to one (or more) subparsers. But in argparse
subparsers have to be explicitly named by the user.
A possible extension is to have the meta-parser look at the context. For example in the OP case, if it sees any of [--list, -p, -m] use the list
subparser, if any of the simulate
arguments, use the simulate
subparser. That might give some more powerful grouping tools. And it might be possible to implement that sort of thing with the stock argparse
. You can create and run several different parsers
on the same sys.argv
.