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.) -- https://mail.python.org/mailman/listinfo/python-list
