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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4