[Python-Dev] Adding Optik to 2.3 standard library (original) (raw)
Greg Ward gward@python.net
Fri, 12 Apr 2002 13:32:31 -0400
- Previous message: [Python-Dev] Adding Optik to 2.3 standard library
- Next message: [Python-Dev] Adding Optik to 2.3 standard library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[please do cc me on this -- I've disabled my python-dev subscription for a while, as I'm going on holiday soon, but I do want to see this thread!]
On 12 April 2002, Barry A. Warsaw said:
Is Greg willing to sign the PSF contributor's agreement ?
In a flash.
Seriously though, the docs should be converted to .tex and there should probably be some unittests for it.
There are tests, but they don't use any testing framework. Might be a good chance to try out PyUnit and see how it stacks up. ;-)
Also, is "optik" the right name for the package in the standard library? It's a great project name, but I'm not so sure that it's as descriptive as it could be (I'm thinking mimelib/email here). "getopt" is taken, but how about "options"?
All of the following have occurred to me:
drop the optik package right into the standard lib as-is, cutesy name and all
same as above, but call it options or option_parser or something (I'm not keen on cloptions, sorry)
same as either of the above, but merge it into a single module -- the 'optik' package in Optik 1.3 is only 1,100 source lines, of which 579 are code, in 3 modules
cat optik/lib/*.py >> Lib/getopt.py and edit until it works (Guido wasn't keen on this in private email)
turn 'getopt' into a package that makes the existing getopt stuff available as well as Optik's OptionParser and Option -- eg. to use the new interface, you would do from getopt import OptionParser, ... instead of from optik import OptionParser
variation on the previous one that uses subtle and clever import- time tricks to avoid importing Optik's ~1,000 lines of code unless they are actually needed, to reduce the run-time impact on existing code that just uses the current getopt module
The advantages of keeping the name "Optik" are:
it has already had some publicity with this name, notably Stephen Figgins' article in onlamp.com
easier for me to convert the docs and test suite
The disadvantages are:
it's not really The Way of the Standard Library
means development of Optik is now tied to Python -- I can't maintain a separate thing called "Optik" (I'm not sure if I want to, though -- there's really not much more to do)
I'm pretty open to whatever consensus arises.
Greg-- Greg Ward - Linux geek gward@python.net http://starship.python.net/~gward/ Hand me a pair of leather pants and a CASIO keyboard -- I'm living for today!
- Previous message: [Python-Dev] Adding Optik to 2.3 standard library
- Next message: [Python-Dev] Adding Optik to 2.3 standard library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]