[Python-3000] packages in the stdlib
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
> 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