[Python-Dev] Proposed standard module: Optik (original) (raw)
Greg Ward gward@python.net
Mon, 11 Feb 2002 15:37:16 -0500
- Previous message: [Python-Dev] Proposed standard module: Optik
- Next message: [Python-Dev] Proposed standard module: Optik
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
--TB36FDmn/VVEgNH/ 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:
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-- Greg Ward - geek gward@python.net http://starship.python.net/~gward/ Save energy: be apathetic.
--TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="competition.txt"
THE COMPETITION
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 then
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 "--file"
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
Options 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)
--TB36FDmn/VVEgNH/--
- Previous message: [Python-Dev] Proposed standard module: Optik
- Next message: [Python-Dev] Proposed standard module: Optik
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]