[Python-Dev] Adding Optik to 2.3 standard library

Greg Ward gward@python.net
Fri, 12 Apr 2002 13:32:31 -0400

[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 <wink>?

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 Ward - Linux geek                                  gward@python.net
Hand me a pair of leather pants and a CASIO keyboard -- I'm living for today!