[Python-Dev] Great Renaming - Straw Man 0.2

[Moshe Zadka]

On Tue, 28 Mar 2000, Greg Ward wrote:

>   * "deep hierarchies considered harmful": ie. avoid sub-packages if at
>     all possible
> 
>   * "everything should have a purpose": every top-level package should
>     be describable with a single, clear sentence of plain language.

Good guidelines, but they aren't enough. And anyway, rules were meant to
be broken <0.9 wink>

>   * "as long as we're renaming...": maybe this would be a good time to
>     standardize naming conventions, eg. "cgi" -> "cgilib" *or*
>     "{http,ftp,url,...}lib" -> "{http,ftp,url}...", "MimeWriter" ->
>     "mimewriter", etc.

+1

>   * "shared namespaces vs system namespaces": the Perl model of "nothing
>     belongs to The System; anyone can add a module in Text:: or Net:: or
>     whatever" works there because Perl doesn't have __init__ files or
>     anything to distinguish module namespaces; they just are.  Python's
>     import mechanism would have to change to support this, and the fact
>     that __init__ files may contain arbitrary code makes this feel
>     like a very tricky change to make.

Indeed. But I still feel that "few things should belong to the system"
is quite a useful rule...
(That's what I referred to when I said Perl's module system is more suited
to CPAN (now there's a surprise))

> Rename?  Either cgi -> cgilib or foolib -> foo?

Yes. But I wanted the first proposal to be just about placing stuff,
because that airs out more disagreements.

> This is one good place for a sub-package.  It's a also a good place to
> rename: the convention for Python module names seems to be
> all-lowercase; and "Server" is redundant when you're in the net.server
> package.  How about:
> 
>     net.server.base_http
>     net.server.cgi_http
>     net.server.simple_http
>     net.server.socket

Hmmmmm......+0

> Underscores negotiable.  They don't seem to be popular in module names,
> although sometimes they would be real life-savers.

Personally, I prefer underscores to CamelCase.

> Or maybe not.  I'm just trying to come up with an excuse for moving xml
> to top-level, which I think is where it belongs.  Maybe the excuse
> should just be, "XML is really important and visible, and anyways Paul
> Prescod will raise a stink if it isn't put at top-level in Python
> package-space".

I still think "xml" should be a brother to "html" and "sgml".
Current political trans not withstanding.

> Not sure what to do about these.  Someone referred somewhere to a "web"
> top-level package, which seems to have disappeared.  If it reappars, it
> would be a good place for the HTML modules (not to mention a big chunk
> of "net") -- this would mainly be for "important and visible" (ie. PR)
> reasons, rather than sound technical reasons.

I think the "web" package should be reinstated. But you won't like it:
I'd put xml in web.

> "mail" should either be top-level or under "net".  (Yes, I *know* it's
> not a wire-level protocol: that's what net.smtplib is for.  But last
> time I checked, email is pretty useless without a network.  And
> vice-versa.)

Ummmm.....I'd disagree, but I lack the strength and the moral conviction.
Put it under net and we'll call it a deal <wink>

> Or maybe these all belong in a top-level "data" package: I'm starting to
> warm to that.

Ummmm...I don't like the "data" package personally. It seems to disobey
your second guideline.

> I agree with Jack: image and sound (audio?) should be top-level.  I
> don't think I like the idea of an intervening "mm" or "multimedia" or
> "media" or what-have-you package, though.

Definitely multimedia. Okay, I'm bought.

> Six crypto-related modules seems like enough to justify a top-level
> "crypt" package, though.

It seemed obvious to me that "crypt" should be under "math". But maybe
that's just the mathematician in me speaking.

> I like "python" for this one.  (But I'm not sure if tabnanny and
> rlcompleter belong there.)

I agree, and I'm not sure about rlcompleter, but am sure about tabnanny.

> What does ihooks have to do with security?

Well, it was more or less written to support rexec. A weak argument,
admittedly

> No problem until these last two -- 'commands' is a Unix-specific thing
> that has very little to do with the filesystem per se

Hmmmmm...it is on the same level with popen. Why not move popen too?

>, and 'dl' is (as I
> understand it) deep ju-ju with sharp edges that should probably be
> hidden away 

Ummmmmm.....not in the "python" package: it doesn't have anything to
do with the interpreter.

> Should this be "sgi" or "irix"?  Ditto for "sun" vs "solaris" if there
> are a significant number of Sun/Solaris modules.  Note that the
> respective trademark holders might get very antsy about who gets to put
> names in those namespaces -- that's exactly what happened with Sun,
> Solaris 8, and Perl.  I believe the compromise they arrived at was that
> the "Solaris::" namespace remains open, but Sun gets the "Sun::"
> namespace.

Ummmmm.....I don't see how they have any legal standing. I for one refuse
to care about what Sun Microsystem thinks about names for Python packages.

> There should probably be a win32 package, for core registry access stuff
> if nothing else.

And for all the other extensions in win32all
Yep! 
(Just goes to show what happens when you decide to package based on a UNIX
system)

> All of those
> argue over "irix" and "solaris" instead of "sgi" and "sun".

Fine with me -- just wanted to move them out of my face <wink>
--
Moshe Zadka <mzadka@geocities.com>. 
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com