argparse and subparsers

[Sachin Garg]

On Monday 27 June 2016 06:28 AM, Steven D'Aprano wrote:
> On Monday 27 June 2016 15:34, Lawrence D’Oliveiro wrote:
> 
>> On Monday, June 27, 2016 at 4:56:10 PM UTC+12, Sachin Garg wrote:
>>
>>> # Set verbose flag
>>> verbose = False
>>> if arguments['--verbose']:
>>>     verbose = True
>>> elif arguments['-q']:
>>>     verbose = False
>>
>> Don’t you just love code (and commenting) like this...
> 
> 
> Not particularly, but what are you going to do? You need to support a minimum 
> of three cases:
> 
> - a default setting;
> - the case where the user passes --verbose;
> - the case where the user passes -q;
> 
> (I'm not sure why --verbose take a long argument but no short argument -v; and 
> likewise why there's a -q short argument but no --quiet long version. Oh well.)

It is there. The way docopt works (https://github.com/docopt/docopt) is
that it uses a "usage pattern" formatted using doctring conventions. In
my case (snippet below), this pattern was:

"""Process Files: De-identify, encrypt and transmit data.

Usage:
    processFiles.py [-hvq] [--config=FILE] [--encryptkey=key]
[--signkey=key] [--no-normalize] [--no-encrypt] [--no-sign]

Options:
    -h --help           show this help message and exit
    -v --verbose        verbose mode
    -q                  quiet mode (default)

    --config=FILE       read configuration FILE (default: config.json)

    --encryptkey=KEY    set GPG encryption key to KEY(default: from
config file)
    --signkey=KEY       set GPG signing key to KEY (default: from config
file)
    --no-normalize      do not normalize CCD/CSV (default: normalize)
    --no-encrypt        do not encrypt output (default: encrypt)
    --no-sign           do not sign output (default: sign)
    --no-transfer       do not transfer output (default: transfer)
"""

So, the short "-v" option is taken care  of.

> A simple test-and-set for each argument is the simplest, most straight-forward 
> way of handling this. It's not *pretty* or *elegant* code, but it is the 
> easiest to read, write and comprehend, and in my opinion much better than 
> alternatives involving ever more arcane method calls to ever more complicated 
> classes.

The code above does seem amateurish. However, I think that it is easier
to "waste" a few variables and allow for the ability to do printf()
debugging, then write code using esoteric data structures.

> I don't have experience with docutils and cannot judge whether or not Sachin's 
> snippets are good or bad examples of use, but find myself going back to the 
> good old fashioned GNU style command line parser whenever I need a few command 
> line options. If you find yourself writing subparsers and "mandatory options" 
> and needing entire help screens to describe single arguments (as in "foo --help 
> arg") then really I think you should give up the pretence that you're dealing 
> with command line options, and you should write a mini-language for your 
> application.
> 
> (hg, git, memcoder, soc etc. I'm talking about you.)