[Python-Dev] Adding Optik to 2.3 standard library (original) (raw)

Barry A. Warsaw barry@zope.com
Fri, 12 Apr 2002 14:09:47 -0400

"TP" == Tim Peters <tim.one@comcast.net> writes:

TP> Since "getopt" is already universally understood as the way to
TP> spell "ah, that's the command-line option parser module", I'd
TP> rather see Optik get exported from getopt, as getopt.XYZ for
TP> some value of XYZ.  Then the name XYZ doesn't have to convey
TP> "command-line option parser" anymore, but just "another one of
TP> those".  Heck, make getopt itself a package.

Ah, +1

Make the existing `getopt' thingie a package, and the current getopt module a sub-module of that package. Name it _getopt.py and export it as getopt.getopt through the package's init.py. You probably need to also export getopt.error this way too for backwards compatibility (is there anything else people still use?).

Next, expose optik.OptionParser as getopt.Parser. Are there any other public names you'd want to expose?

This brings up an interesting meta issue, related to migrating these independent projects back into Python's standard library. My experience with the email package suggests something that could make life a little easier:

Allow for a setup.py to live inside the directory it's packaging up. In standalone mimelib, I had to have a mostly useless two level directory structure to support distutils, but that structure isn't convenient for the stdlib. If I could move setup.py into Lib/email then I could easily do development inside the stdlib and then just package up a tarball for independent release whenever I felt like it.

All the other package metadata, i.e. README, MANIFEST, etc. could easily live in Lib/email too, although setup.py would have to stitch in the tests, which live in a different hierarchy removed from Lib/email.

-Barry