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