Python dependencies between groups using argparse

前端 未结 3 1689
轻奢々
轻奢々 2021-02-09 13:13

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

3条回答
  •  我寻月下人不归
    2021-02-09 13:57

    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.

提交回复
热议问题