Two views of the argparse module

September 19, 2012

A commentator on my earlier entry about the options problem asked what I thought about the argparse module. I previously hadn't looked at it because of Python version issues, but their question prompted me to go read the documentation and form some opinions.

There are two different views of how command line parsing libraries and modules should behave. In the first view, part of the job of these libraries is to be opinionated and to only support what (Unix) people have decided are good practices for handling command line arguments. The venerable getopt module is opinionated in this way. If you use getopt you get quite a number of good practices behaviors and you have no choice about it. One of the advantages of this is uniformity; if a program uses getopt, you know that it will accept switches in any order, that you can write either '-fARG' or '-f ARG', and so on. If you want to break the rules and parse your arguments in a significantly different way, an opinionated module will not help you. One result of this is that there are perfectly good traditional Unix commands that can't parse their command lines with getopt because they have requirements that it doesn't support.

The second view of command line parsing libraries is that their job is merely helping you parse command line arguments in whatever way you want to do so. While they may make it easier to follow conventions they will not require that you do and will support as much wackiness as they can fit in a sensible API. Order-dependent switches? Optional arguments that take more than one parameter? Sure, whatever, the library will support you doing that. In their flexibility these libraries can be used to enable various levels of bad command line argument handling, argument handling that is completely at odds with how people expect things to behave. On the other hand they can be used to parse command lines that have various sorts of non-traditional behavior (depending on how clever and complex the library API is), stuff that an opinionated library will not deign to touch, instead of forcing you to do it all by hand (and likely doing a worse, less flexible job).

Argparse is the second sort of command line parsing module. It can be used to assemble command line parsers that behave in ways that I do not like at all and have violent reactions to, which strongly biases me against argparse's mere presence in the Python standard library and leaves me feeling that sure, argparse is more flexible than optparse but the flexibility is generally not an improvement.

(Note that optparse states up front that it is an opinionated module; see this.)

As a result of this and the Python version issue, I don't expect to use argparse any time soon. People who have a different view on flexible argument parsing versus standardized argument parsing are likely to have a different view on argparse versus optparse.

Written on 19 September 2012.
« My Python versions
My alternative to bookmarks: a page of links as the browser start page »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Sep 19 00:38:36 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.