I think it's time to declare the work of the getopt-sig finished:
several competing proposals were put forward, but Optik appears to be
the only really complete, documented, field-tested (by someone other
than its author) library. Not everyone on the getopt-sig will agree,
but I think that's the broad consensus. Take this with a grain of salt,
though -- I'm biased. ;-)
Anyways, I think further consensus is needed on how precisely to add
Optik to the standard library. The only constraint I've heard from
Guido is to give it a less-cutesy name, which is fine by me.
First, background: Optik consists of three modules: optik.option,
optik.option_parser, and optik.errors, but that detail is hidden from
users -- Optik applications normally just do this:
from optik import OptionParser
although there are a handful of other names that are occasionally useful
to import from the 'optik' package: Option, SUPPRESS_HELP,
OptionValueError, etc. Optik's __init__.py file is here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/optik/optik/lib/__init__.py?rev=1.11&content-type=text/plain
It's only about 1100 lines, including docs and comments and blanks, so
they could easily be merged into one module if people think that's
preferable.
So the main issues are 1) where those names should be imported from
(interface), and 2) how the standard library should be rearranged to
make this interface unobtrusive and efficient (implementation).
I'm going to toss out ideas at random until I get bored. Please provide
feedback and/or extra ideas on getopt-sig@python.org.
IDEA #1:
interface:
from getopt import OptionParser # and the other Optik names
implementation:
* turn the getopt module into a package
* put the current getopt.py into, say, getopt/classic_getopt.py
* make getopt/__init__.py import everything from classic_getopt.py
and Optik's three modules, so that either interface is there
for the asking
pros:
* dead simple
cons:
* applications using just the classic getopt interface suddenly
find themselves importing lots more code than they used to
IDEA #2:
interface:
from getopt.option_parser import OptionParser, ...
implementation:
* as before, getopt.py becomes getopt/classic_getopt.py
* getopt/__init__.py consists solely of "from classic_getopt import *"
* Optik's three modules are copied into getopt, with the right
imports added to getopt/option_parser.py so that applications
don't have to worry about where Optik's other names come from
pros:
* only slightly more burden on apps now using classic getopt
cons:
* interface is a tad clunkier
IDEA #3:
interface:
from getopt.option_parser import OptionParser, SUPPRESS_HELP, ...
from getopt.option import Option
from getopt.errors import OptionValueError
implementation:
* classic getopt handled the same as #2
* just dump Optik's three modules into getopt/ and be done with it
pros:
* dead simple
cons:
* clunky interface -- imports expose a lot of implementation detail
IDEA #4:
interface:
same as #1
implementation:
* same as #1, except use some funky import-time magic to ensure
that the Optik code is only imported if someone actually needs
it. Barry Warsaw provided a patch to do this:
http://sourceforge.net/tracker/index.php?func=detail&aid=544175&group_id=38019&atid=421099
pros:
* more efficient for apps using classic getopt
cons:
* more complicated; apparently Guido expressed distaste for the
import-time magic. I'm a little leery of it myself, although
I have not carefully read the code.
Preferences? Other ideas? Surely the right solution is out there
somewhere, just beyond my reach...
Greg
--
Greg Ward - Unix geek gward@python.net
http://starship.python.net/~gward/
"Passionate hatred can give meaning and purpose to an empty life."
-- Eric Hoffer
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4