[Python-3000] packages in the stdlib

[Brett Cannon]

On 6/1/06, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
>
> 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.


Right.  And as Paul said in his email, the os module has shown this is not
an issue.  As long as the names are known ahead of time there is not much of
a problem.

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.


Well, personally I would like to clean up the stdlib, but I don't want to
make it too lean since the whole "Batteries Included" thing is handy.  As
for sanctioned libraries that don't come included, that could be possible,
but the politics of picking the libraries could be nasty.

>
> > 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 [*].


Yeah, something better than .pth files would be good.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060601/5b596939/attachment.htm