Two views of the argparse module
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
you know that it will accept switches in any order, that you can write
-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
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.
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.