[Python-Dev] Great Renaming - Straw Man 0.2
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...
> whatever the xml-sig puts here
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?
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?
I like this. Good idea.
Shouldn't "aifc" be under "sound"?
How about just "interp"?
Why the separate "lowlevel" branch?
Why doesn't "socket" go under "net"?
Why does "terminal" belong under "file"?
Maybe it could go under "ui"? Hmm... "pty" doesn't
"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.
On second thought, maybe "struct" fits better under "bin".
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
Hmm. Yes, i suppose so.
Yeah, these are all top-level (except maybe UserDict and
UserList, see above).
I think "locale" belongs under "math" with "fpformat" and
the others. It's for numeric formatting.
What the heck is "pure"?
This probably goes under "text".
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:
They all seem to be Unix-related. How about putting these
in a "unix" or "system" package?
"I'm not trying not to answer the question; i'm just not answering it."
-- Lenore Snell