argparse and subparsers
Sachin Garg
s.garg.computer at gmail.com
Mon Jun 27 13:22:13 EDT 2016
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.)
More information about the Python-list
mailing list