On 1-jun-2006, at 13:29, Paul Moore wrote: > On 5/31/06, Brett Cannon <[EMAIL PROTECTED]> wrote: >> Why would a 3rd-party module be installed into the stdlib namespace? >> net.jabber wouldn't exist unless it was in the stdlib or the >> module's author >> decided to be snarky and inject their module into the stdlib >> namespace. > > Do you really want the stdlib to "steal" all of the simple names (like > net, gui, data, ...)? While I don't think it's a particularly good > idea for 3rd party modules to use such names, I'm not too keen on > having them made effectively "reserved", either.
That was my feeling too, except that I haven't made my mind up on the merit of having 3th-party modules inside such packages. I don't think the risk of nameclashes would be greater than it is now, there's already an implicit nameing convention, or rather several of them ;-), for naming modules in the standard library. The main problem I have with excluding 3th-party libraries from such generic toplevel packages in the standard library is that this increases the separation between stdlib and other code. I'd rather see a lean&mean standard library with a standard mechanism for adding more libraries and perhaps a central list of good libraries. > > And if there was a "net" package which contained all the networking > modules in the stdlib, then yes I would expect a 3rd party developer > of a jabber module to want to take advantage of the hierarchy and > inject itself into the "net" namespace. Which would actually make name > collisions worse rather than better. [Although, evidence from the > current os module seems to imply that this is less of an issue than > I'm claiming, in practice...] I suppose that's at least partially not an issue at the moment because you can only add stuff to existing packages through hacks. I wouldn't touch libraries that inject themselves into existing packages through .pth hackery because of the juckyness of it [*]. Ronald _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
