[Python-Dev] Great Renaming - Straw Man 0.2

Ka-Ping Yee ping@lfw.org
Sat, 25 Mar 2000 21:01:58 -0800 (PST)


On Sun, 26 Mar 2000, Moshe Zadka wrote:
> Here's a second version of the straw man proposal for the reorganization
> of modules in packages. Note that I'm treating it as a strictly 1.7
> proposal, so I don't care a "lot" about backwards compatiblity.

Hey, this looks pretty good.  For the most part i agree with
your layout.  Here are a few notes...

> net
[...]
> 	server
[...]

Good.

> text
[...]
> 	xml
> 		whatever the xml-sig puts here
> 	mail
> 		rfc822
> 		mime
> 			MimeWriter
> 			mimetools
> 			mimify
> 			mailcap
> 			mimetypes
> 			base64
> 			quopri
> 		mailbox
> 		mhlib
> 	binhex

I'm not convinced "mime" needs a separate branch here.
(This is the deepest part of the tree, and at three levels
small alarm bells went off in my head.)

For example, why text.binhex but text.mail.mime.base64?

> 	parse
> 		string
> 		re
> 		regex
> 		reconvert
> 		regex_syntax
> 		regsub
> 		shlex
> 	ConfigParser
> 	linecache
> 	multifile
> 	netrc

The "re" module, in particular, will get used a lot,
and it's not clear why these all belong under "parse".
I suggest dropping "parse" and moving these up.
What's "multifile" doing here instead of with the rest
of the mail/mime stuff?

> bin
[...]

I like this.  Good idea.

> 	gzip
> 	zlib
> 	aifc

Shouldn't "aifc" be under "sound"?

> 	image
[...]
> 	sound
[...]

> db
[...]

Yup.

> math
[...]
> time
[...]

Looks good.

> interpreter
[...]

How about just "interp"?

> security
[...]

> file
[...]
> 	lowlevel
> 		socket
> 		select

Why the separate "lowlevel" branch?
Why doesn't "socket" go under "net"?

> 	terminal
> 		termios
> 		pty
> 		tty
> 		readline

Why does "terminal" belong under "file"?
Maybe it could go under "ui"?  Hmm... "pty" doesn't
really belong.

> 	syslog

Hmm...

> serialize

> 	pickle
> 	cPickle
> 	shelve
> 	xdrlib
> 	copy
> 	copy_reg

"copy" doesn't really fit here under "serialize", and
"serialize" is kind of a long name.

How about a "data types" package?  We could then put
"struct", "UserDict", "UserList", "pprint", and "repr" here.

    data
        copy
        copy_reg
        pickle
        cPickle
        shelve
        xdrlib
        struct
        UserDict
        UserList
        pprint
        repr

On second thought, maybe "struct" fits better under "bin".

> threads
[...]
> ui
[...]

Uh huh.

> internal
> 	_codecs
> 	_locale
> 	_tkinter
> 	pcre
> 	strop
> 	posix

Not sure this is a good idea.  It means the Unicode
work lives under both "unicode" and "internal._codecs",
Tk is split between "ui" and "internal._tkinter",
regular expressions are split between "text.re" and
"internal.pcre".  I can see your motivation for getting
"posix" out of the way, but i suspect this is likely to
confuse people.

> users
> 	pwd
> 	grp
> 	nis

Hmm.  Yes, i suppose so.

> sgi
[...]
> unicode
[...]

Indeed.

> os
> UserDict
> UserList
> exceptions
> types
> operator
> user
> site

Yeah, these are all top-level (except maybe UserDict and
UserList, see above).

> locale

I think "locale" belongs under "math" with "fpformat" and
the others.  It's for numeric formatting.

> pure

What the heck is "pure"?

> formatter

This probably goes under "text".

> struct

See above under "data".  I can't decide whether "struct"
should be part of "data" or "bin".  Hmm... probably "bin" --
since, unlike the serializers under "data", "struct" does
not actually specify a serialization format, it only provides
fairly low-level operations.

Well, this leaves a few system-like modules that didn't
really fit elsewhere for me:

    pty
    tty
    termios
    syslog
    select
    getopt
    signal
    errno
    resource

They all seem to be Unix-related.  How about putting these
in a "unix" or "system" package?



-- ?!ng

"I'm not trying not to answer the question; i'm just not answering it."
    -- Lenore Snell