[Python-Dev] Proposed standard module: Optik

Greg Ward gward@python.net
Mon, 11 Feb 2002 15:37:16 -0500

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On 11 February 2002, I said:
> A good starting point for modules that compete with Optik can be found
> in "User Interfaces" section of the Vaults of Parnassus:
>   http://www.vex.net/parnassus/apyllo.py/808292924

OK, I've looked at all the option-parsing packages listed in Parnassus.
I've read the docs for all of them, and flipped through the source for
some of them.  Here's the executive summary:

  * only one of them, arglist.py by Ben Wolfson, has a nice OO
    design similar to Optik

  * the one feature that several of the competition offer but Optik
    does not (yet) is the ability to specify an option that *may*
    take a value, but doesn't necessarily *have to* take a value.
    Ironically, this is one of my requirements for the Distutils,
    motivated by the --home option to the "install" command.

I think arglist.py is the only serious contender here.  Based on my
cursory inspection, all of the others have rather deep flaws.  (Eg. they
implement a non-standard syntax, or they do all their work at import
time rather than providing a class to instantiate and do option-parsing
work, or they have painful/awkward/hairy programming interface.)

I'll attach my full notes.  Anyone else who feels like doing this should
start at the *bottom* of the list on Parnassus, since I devoted
progressively less time and energy to each package along the way.  ;-)

Greg Ward - geek                                        gward@python.net
Save energy: be apathetic.

Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="competition.txt"


arglist.py (Feb 2002)
  author: Ben Wolfson <rumjuggler@cryptarchy.org>
  url:    http://home.uchicago.edu/~wolfson/Python/

  * fairly clean OO design, much like Optik: Option for each option,
    Argument for a collection of options

  * results of parsing command line (option values and leftover
    positional args) are accessible through Arguments object -- no
    separate "option values" object

  * handles short options much like Optik: "-ffoo" and "-f foo" seem to
    work, as does "-avx" where -a, -v, -x all value-less options

  * subtly different notion of "default value" from Optik -- if an
    option takes a value, and no default value is provided, the user
    must provide a value.  With Optik (<= 1.2), if an option takes a
    value the user must always provide a value; the default value is for
    when that option isn't present at all.

  * dependent on Python 2.2 -- even uses a metaclass! (not that
    it really *needs* to)

  * no strong typing, much weaker callback interface; but "behaviors"
    are like Optik's "actions" -- there just aren't as many of them

  * main advantage over Optik: it's possible to define an option
    that takes a value, but doesn't require a value

  * error-handling?  not sure -- think it raises an exception

  * long option abbreviations allowed? not sure

Cmdline (1.0)
  author: Daniel Gindikin <dan@netrics.com>
  url: http://members.home.com/gindikin/dev/python/cmdline/

  * weird API: just import the module and it does everything

  * slightly weird user interface: in addition to the standard
    "--foo=bar" and "--foo bar", "foo=bar" and "foo:bar" also
    work: yuck

  * very cool error-handling: prints out the command-line, underlining
    the option with errors -- nice!

  * rudimentary type-checking -- if you ask for an integer value, and
    user supplied a string, it bombs with a useful error message

  * not extensible -- everything's done at module-level, no classes
    or anything nice like that

  * long option abbreviations allowed? not sure

Getargs (1.3)
  author: ? (Ivan Van Laningham?)
  url: http://www.pauahtun.org/ftp.html

  * painful, clunky interface (eg. None specifies a boolean option,
    0j a "count" option, 0 an integer option, 0.0 a float option)

  * I don't see how to specify a plain old string option!

  * documentation is confusing and poorly written

  * "long options" are Tk-style, eg. "-file", rather than GNU-style

  * order of options is lost -- not clear what happens if user does
    -ffoo -fbar? what is the value of -f?

  * long options can be abbreviated

  * last updated 1999

GetPot Python
  author: Frank-Rene Schaefer
  url: http://getpot.sourceforge.net/

  * written in C++, so an extension is needed... or is it?  not clear

  * docs cover C++ version

  * LGPL'd

  * seems to define a mini-language for defining command-line options;
    not sure where you're supposed to put those .pot source files

  author: Tim Colles <timc@dai.ed.ac.uk>
          Johan Vromans <jvromans@squirrel.nl>

  * port of Perl's Getopt::Long

  * not really OO or extensible, as near as I could tell

  * possible to specify option types and required-ness, but the
    syntax is hairy -- I think it's all done in one fell swoop
    (single call to GetOptions() does everything)