On Sat, 25 Mar 2000, Ka-Ping Yee wrote:
> 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.)
I've had my problems with that too, but it seemed to many modules were
mime specific.
> For example, why text.binhex but text.mail.mime.base64?
Actually, I thought about this (this isn't random at all): base64 encoding
is part of the mime standard, together with quoted-printable. Binhex
isn't. I don't know if you find it reason enough, and it may be smarter
just having a text.encode.{quopri,uu,base64,binhex}
> > parse
> > string
> > re
> > regex
> > reconvert
> > regex_syntax
> > regsub
> > shlex
> > ConfigParser
> > linecache
> > multifile
> > netrc
>
> The "re" module, in particular, will get used a lot,
and
from <something> import re
Doesn't seem too painful.
> and it's not clear why these all belong under "parse".
These are all used for parsing data (which does not have some pre-written
parser). I had problems with the name too...
> What's "multifile" doing here instead of with the rest
> of the mail/mime stuff?
It's also useful generally.
> Shouldn't "aifc" be under "sound"?
You're right.
> > interpreter
> [...]
>
> How about just "interp"?
I've no *strong* feelings, just a vague "don't abbrev." hunch <wink>
> Why the separate "lowlevel" branch?
Because it is -- most Python code will use one of the higher level
modules.
> Why doesn't "socket" go under "net"?
What about UNIX domain sockets? Again, no *strong* opinion, though.
> > terminal
> > termios
> > pty
> > tty
> > readline
>
> Why does "terminal" belong under "file"?
Because it is (a special kind of file)
> > serialize
>
> > pickle
> > cPickle
> > shelve
> > xdrlib
> > copy
> > copy_reg
>
> "copy" doesn't really fit here under "serialize", and
> "serialize" is kind of a long name.
I beg to disagree -- "copy" is frequently close to serialization, both in
the model (serializing to a "data structure") and in real life (that's the
way people copy stuff in Java, and UNIX too: think tar cvf - | tar xvf -)
What's more, copy_reg is used both for copy and for pickle
I do like the idea of "data-types" package, but it needs to be ironed
out a bit.
> > 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.
You mistook my motivation -- I just want unadvertised modules (AKA
internal use modules) to live in a carefully segregate section of the
namespace. How would this confuse people? No one imports _tkinter or pcre,
so no one would notice the change.
> > locale
>
> I think "locale" belongs under "math" with "fpformat" and
> the others. It's for numeric formatting.
Only? And anyway, I doubt many people will think like that.
> > pure
>
> What the heck is "pure"?
A module that helps work with purify.
> > formatter
>
> This probably goes under "text".
You're right.
> 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?
"select", "signal" aren't UNIX specific.
"getopt" is used for generic argument processing, so it isn't really UNIX
specific. And I don't like the name "system" either. But I have no
constructive proposals about thos either.
so-i'll-just-shut-up-now-ly y'rs, Z.
--
Moshe Zadka <mzadka@geocities.com>.
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com
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