[Python-Dev] Great Renaming - Straw Man 0.2

[Greg Ward]

On 25 March 2000, Ka-Ping Yee said:
> Okay, here's another shot at it.  Notice a few things:

Damn, I started writing a response to Moshe's original proposal -- and
*then* saw this massive thread.  Oh well.  Turns out I still have a few
useful things to say:

First, any organization scheme for the standard library (or anything
else, for that matter) should have a few simple guidelines.  Here are
two:

  * "deep hierarchies considered harmful": ie. avoid sub-packages if at
    all possible

  * "everything should have a purpose": every top-level package should
    be describable with a single, clear sentence of plain language.
    Eg.:
       net - Internet protocols, data formats, and client/server infrastructure
       unix - Unix-specific system calls, protocols, and conventions

And two somewhat open issues:

  * "as long as we're renaming...": maybe this would be a good time to
    standardize naming conventions, eg. "cgi" -> "cgilib" *or*
    "{http,ftp,url,...}lib" -> "{http,ftp,url}...", "MimeWriter" ->
    "mimewriter", etc.

  * "shared namespaces vs system namespaces": the Perl model of "nothing
    belongs to The System; anyone can add a module in Text:: or Net:: or
    whatever" works there because Perl doesn't have __init__ files or
    anything to distinguish module namespaces; they just are.  Python's
    import mechanism would have to change to support this, and the fact
    that __init__ files may contain arbitrary code makes this feel
    like a very tricky change to make.

Now specific comments...

> net
>         urlparse
>         urllib
>         ftplib
>         gopherlib
>         imaplib
>         poplib
>         nntplib
>         smtplib
>         telnetlib
>         httplib
>         cgi

Rename?  Either cgi -> cgilib or foolib -> foo?

>         server
>                 BaseHTTPServer
>                 CGIHTTPServer
>                 SimpleHTTPServer
>                 SocketServer
>                 asynchat
>                 asyncore

This is one good place for a sub-package.  It's a also a good place to
rename: the convention for Python module names seems to be
all-lowercase; and "Server" is redundant when you're in the net.server
package.  How about:

    net.server.base_http
    net.server.cgi_http
    net.server.simple_http
    net.server.socket

Underscores negotiable.  They don't seem to be popular in module names,
although sometimes they would be real life-savers.

> text

I think "text" should mean "plain old unstructured, un-marked-up ASCII
text", where "unstructured, un-marked-up" really means "not structured
or marked up in a well-known standard way".

Or maybe not.  I'm just trying to come up with an excuse for moving xml
to top-level, which I think is where it belongs.  Maybe the excuse
should just be, "XML is really important and visible, and anyways Paul
Prescod will raise a stink if it isn't put at top-level in Python
package-space".

>         re              # general-purpose parsing
 
Top-level: this is a fundamental module that should be treated on a par
with 'string'.  (Well, except for building RE methods into
strings... hmmMMmm...maybe... [no, I'm kidding!])

>         sgmllib
>         htmllib
>         htmlentitydefs

Not sure what to do about these.  Someone referred somewhere to a "web"
top-level package, which seems to have disappeared.  If it reappars, it
would be a good place for the HTML modules (not to mention a big chunk
of "net") -- this would mainly be for "important and visible" (ie. PR)
reasons, rather than sound technical reasons.

>         xml
>                 whatever the xml-sig puts here

Should be top-level.

>         mail
>                 rfc822
>                 mailbox
>                 mhlib

"mail" should either be top-level or under "net".  (Yes, I *know* it's
not a wire-level protocol: that's what net.smtplib is for.  But last
time I checked, email is pretty useless without a network.  And
vice-versa.)

Or maybe these all belong in a top-level "data" package: I'm starting to
warm to that.

> bin
>         gzip
>         zlib
>         chunk
>         struct
>         image
>                 imghdr
>                 colorsys        # a bit unsure, but doesn't go anywhere else
>                 imageop
>                 imgfile
>                 rgbimg
>                 yuvconvert
>         sound
>                 aifc
>                 sndhdr
>                 toaiff
>                 audiodev
>                 sunau
>                 sunaudio
>                 wave
>                 audioop
>                 sunaudiodev

I agree with Jack: image and sound (audio?) should be top-level.  I
don't think I like the idea of an intervening "mm" or "multimedia" or
"media" or what-have-you package, though.

The other stuff in "bin" is kind of a grab-bag: "chunk" and "struct"
might belong in the mythical "data" package.

> db
>         anydbm
>         whichdb
>         bsddb
>         dbm
>         dbhash
>         dumbdbm
>         gdbm

Yup.

> math
>         math            # library functions
>         cmath
>         fpectl          # type-related
>         fpetest
>         array
>         mpz
>         fpformat        # formatting
>         locale
>         bisect          # algorithm: also unsure, but doesn't go anywhere else
>         random          # randomness
>         whrandom
>         crypt           # cryptography
>         md5
>         rotor
>         sha

Hmmm.  "locale" has already been dealt with; obviously it should be
top-evel.  I think "array" should be top-level or under the mythical
"data".

Six crypto-related modules seems like enough to justify a top-level
"crypt" package, though.

> time
>         calendar
>         time
>         tzparse
>         sched
>         timing

Yup.

> interp
>         new
>         linecache       # handling .py files
[...]
>         tabnanny
>         pstats
>         rlcompleter     # this might go in "ui"...

I like "python" for this one.  (But I'm not sure if tabnanny and
rlcompleter belong there.)

> security
>         Bastion
>         rexec
>         ihooks

What does ihooks have to do with security?

> file
>         dircache
>         path -- a virtual module which would do a from <something>path import *
>         nturl2path
>         macurl2path
>         filecmp
>         fileinput
>         StringIO

Lowercase for consistency?

>         glob
>         fnmatch
>         stat
>         statcache
>         statvfs
>         tempfile
>         shutil
>         pipes
>         popen2
>         commands
>         dl

No problem until these last two -- 'commands' is a Unix-specific thing
that has very little to do with the filesystem per se, and 'dl' is (as I
understand it) deep ju-ju with sharp edges that should probably be
hidden away in the 'python' ('sys'?) package.

Oh yeah, "dl" should be elsewhere -- "python" maybe?  Top-level?
Perhaps we need a "deepmagic" package for "dl" and "new"?  ;-)

> data
>         pickle
>         shelve
>         xdrlib
>         copy
>         copy_reg
>         UserDict
>         UserList
>         pprint
>         repr
>         (cPickle)

Oh hey, it's *not* a mythical package!  Guess I didn't read far enough
ahead.  I like it, but would add more stuff to it (obviously): 'struct',
'chunk', 'array' for starters.

Should cPickle be renamed to fastpickle?

> threads
>         thread
>         threading
>         Queue

Lowercase?

> ui
>         _tkinter
>         curses
>         Tkinter
>         cmd
>         getpass
>         getopt
>         readline

> users
>         pwd
>         grp
>         nis

These belong in "unix".  Possibly "nis" belongs in "net" -- do any
non-Unix OSes use NIS?

> sgi
>         al
>         cd
>         cl
>         fl
>         fm
>         gl
>         misc (what used to be sgimodule.c)
>         sv

Should this be "sgi" or "irix"?  Ditto for "sun" vs "solaris" if there
are a significant number of Sun/Solaris modules.  Note that the
respective trademark holders might get very antsy about who gets to put
names in those namespaces -- that's exactly what happened with Sun,
Solaris 8, and Perl.  I believe the compromise they arrived at was that
the "Solaris::" namespace remains open, but Sun gets the "Sun::"
namespace.

There should probably be a win32 package, for core registry access stuff
if nothing else.  There might someday be a "linux" package; it's highly
unlikely there would be a "pc" or "alpha" package though.  All of those
argue over "irix" and "solaris" instead of "sgi" and "sun".

        Greg