[Python-Dev] Adding Optik to 2.3 standard library

[Barry A. Warsaw]

>>>>> "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