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