Unix users understand the power of the command line. On the command line you can pass arguments to your applications as easily as you would pass an argument to a function. Standard Unix convention is to pass arguments prefixed by a
--. Some options can be specified in more than one way
--file, for example. Some can be combined, like GNU's
-xvfz, to verbosely expand a compressed file. The more options you have, the more code you need to parse them properly. Options are simple to implement.
Python even includes a getopt module which retrieves your specified
arguments and places them in a list..
Parsing and handling options is so simple that when Greg Ward announced Optik, a command-line parsing library, I asked him why he would even bother. He replied, "The problem is not that it's difficult per se, but that it's too easy -- any idiot can code a loop over sys.argv. The trick is turning this loop into a decent user interface, and coding it in a reusable way. Coding the same loop over sys.argv in every script you write gets old pretty fast, which is probably why this is the most over-invented wheel in the Unix community."
So, what's wrong with the getopt module? "It doesn't do enough",
Ward says. "All it does is turn 'loop over sys.argv' into 'loop over
the options found in sys.argv.' You still end up coding that loop in
every script you write. All Python's standard getopt buys you is not
having to worry about the many different meanings of
This isn't the first time Ward has reinvented the options wheel. He wrote the fancy_getopt module found in Distutils, the Getopt::Tabular perl module available on CPAN, and a couple of other modules that were never released publicly. One of those was the immediate precursor to Optik.
What makes Optik special, what made it possible, was Ward's separation of types and actions. Ward uses types to specify what kind of a thing a paramater is. Ward says with Getopt::Tabular, back in 1996, he was asking too much of types, trying to provide support for more complex types, like lists, for example. With Optik he only has three types by default, strings, integers or floats. If you want more, (say to create a type 'file'), you can subclass the Option class.
But you won't need to often because in late 2001, Ward hit upon the solution to keeping his types simple: actions. Actions specify what should be done with an option, perhaps storing it, or appending it to a list, incrementing a count, or even invoking a callback function. Callbacks are especially handy for options that might take a variable number of arguments. You can also extend actions.
Between the basic types, actions, callback functions, and the ability to extend types and actions, Optik is flexible enough to handle the most tangled sets of options. Adding to the complete and polished feel of Optik, Ward's documentation for Optik is top notch. It's easy to get started with Optik.
Coming in the 1.2.1 release are default types and destinations that simplify the syntax for some options, and an example directory with examples demonstrating extensions. Ward plans to implement some of the most often requested features as extensions. These are minor tweaks to a solid and feature rich module. I will be surprised if Optik doesn't soon make it into the Python Standard Library.
Stephen Figgins administrates Linux servers for Sunflower Broadband, a cable company.
Read more Python News columns.
Return to the Python DevCenter.