argparse and subparsers

Steven D'Aprano steve+comp.lang.python at pearwood.info
Mon Jun 27 06:28:49 EDT 2016


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.)

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.

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.)



-- 
Steve




More information about the Python-list mailing list