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