argparse: parse specific options first, while having all options shown in usage hint
Question: I have an application whose options handling partially depends on the value
given for other options, as in

    
    
    python tool.py --limit=s:100 stuff property
    

A simple argument parser could look like this:

    
    
    import argparse
    parser=argparse.ArgumentParser()
    parser.add_argument('--limit')
    parser.add_argument('stuff')
    parser.add_argument('property')
    args = parser.parse_args(['--limit', 's:100', 'something', '123'])
    

However, how the `--limit` argument must be handled depends on both `stuff`
and `property`. I could make `--limit` unknown to the parser, parse only known
arguments with

    
    
    args, unknown = parser.parse_known_args(['--limit', 's:100', 'something', '123'])
    

and pass `unknown` to a second parser which can act according to the values of
`stuff` and `property`, but then I couldn't include the second parser's help
in the output of `python tool.py --help`, or could I?


Answer: You could give the first parser a custom `usage` parameter that includes all
the arguments. You could write that by hand, or fetch it from a (unused)
parser that includes all arguments.

    
    
     astr = parser.format_usage()
    

fetches the usage string

    
    
     parser = ArgumentParser(usage=astr,...)
    

passes it to a new parser. You may need to edit `astr` a bit.

Including the extra `help` lines will be trickier. You could add them to the
`description` or `epilog`.

* * *

The order in which arguments are parsed is determined by their order in the
`sys.argv`. The parser looks for positional arguments, then an optional, more
positionals, next optional, etc until the strings are consumed.

As matter of philosophy I prefer to think of `argparse` as a parser, not a
'handler'. It's primary purpose is to figure out what the user wants, and it
give useful feedback if they want something unexpected.

Interactions between arguments are best handled after parsing. It is possible
to implement interactions with custom Action classes, but that code typically
gets more complex.

In your example `--limit` occurs first, putting 's:100' in the namespace

Initial namespace with defaults:

    
    
    namespace(limit=None, stuff=None, property=None)
    

namespace after parsing `--limit`:

    
    
    namespace(limit='s:100', stuff=None, property=None)
    

namespace after parsing the 2 positionals:

    
    
    namespace(limit='s:100', stuff='something', property=123)
    

The `limit` custom Action could look at the values for `stuff` and `property`,
but that doesn't help if those strings come after. Similarly, `stuff` action
could look at and modify the `limit` attribute, but a latter `--limit` could
overwrite that.

If you expand on how these arguments interact we could give you more concrete
ideas.

* * *

Another thought - use one parser to handle the help, and handle `--limit` in a
most general way. Then creat or modify a new parser using the useful values
from the first, and parse the input again. The same `sys.argv` can be parsed
multiple times by multiple parsers. Nothing is destroyed in parsing.

