[Python-Dev] Great Renaming - Straw Man 0.2

[Ka-Ping Yee]

On Sun, 26 Mar 2000, Moshe Zadka wrote:
> > 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}

I think i'd like that better, yes.

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

And parsing is what the "text" package is about anyway.
I say move them up.  (See the layout in my other message.
Notice most of the regular-expression stuff is deprecated
anyway, so it's not like there are really that many.)

> > Why doesn't "socket" go under "net"?
> 
> What about UNIX domain sockets? Again, no *strong* opinion, though.

Bleck, you're right.  Well, i think we just have to pick one
or the other here, and i think most people would guess "net"
first.  (You can think of it as IPC, and file IPC-related
things under then "net" category...?)

> > Why does "terminal" belong under "file"?
> 
> Because it is (a special kind of file)

Only in Unix.  It's Unix that likes to think of all things,
including terminals, as files.

> I do like the idea of "data-types" package, but it needs to be ironed 
> out a bit.

See my other message for a possible suggested hierarchy...

> > > internal
[...]
> 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.

I think it makes more sense to classify modules by their
topic rather than their exposure.  (For example, you wouldn't
move deprecated modules to a "deprecated" package.)

Keep in mind that (well, at least to me) the main point of
any naming hierarchy is to avoid name collisions.  "internal"
doesn't really help that purpose.  You also want to be sure
(or as sure as you can) that modules will be obvious to find
in the hierarchy.  An "internal" package creates a distinction
orthogonal to the topic-matter distinction we're using for the
rest of the packages, which *potentially* introduces the
question "well... is this module internal or not?" for every
other module.  Yes, admittedly this is only "potentially",
but i hope you see the abstract point i'm trying to make...

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

Yeah, it is pretty much only for numeric formatting.  The
more generic locale stuff seems to be in _locale.

> > They all seem to be Unix-related.  How about putting these
> > in a "unix" or "system" package?
> 
> "select", "signal" aren't UNIX specific.

Yes, but when they're available on other systems they're an
attempt to emulate Unix or Posix functionality, aren't they?

> Well, the argument style it processes is not unheard of in other OSes, and
> it's nice to have command line apps that have a common ui. That's it!
> "getopt" belongs in the ui package!

I like ui.getopt.  It's a pretty good idea.


-- ?!ng

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