[Python-Dev] Great Renaming - Straw Man 0.2

[Moshe Zadka]

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