[Python-3000] packages in the stdlib

Ronald Oussoren ronaldoussoren at mac.com
Thu Jun 1 16:51:03 CEST 2006

On 1-jun-2006, at 13:29, Paul Moore wrote:

> On 5/31/06, Brett Cannon <brett at python.org> 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 [*].


More information about the Python-3000 mailing list