[Python-3000] packages in the stdlib

[Ronald Oussoren]

On 1-jun-2006, at 17:44, Brett Cannon wrote:

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

And as I noted that's probably because the only ways to transparently  
patch the os module are evil .pth tricks and replacing files in the  
standard library. Neither are considered good style and therefore not  
something you'd do if you want someone to use your library. How would  
you react to a library on the cheeseshop that claims to add some  
useful functions to the os module? I'd be very, very hesitant to use  
such (hypothetical) library.

There is however nothing wrong with naming a library tftplib. That's  
would be the obvious name for a library that supports TFTP and blends  
nicely with the standard library naming convention for network  
libraries. It would be nice if 3th-party libraries could blend in  
even with a more structured standard library, even if that would only  
be possible for carefully selected portions of the standard library.

Not that this is a really big issue, the range of libraries on the  
cheeseshop is much, much larger than the functionality covered by the  
standard library ;-). There are of course also good reason for not  
wanting to follow the standard library conventions. Even if the  
stdlib would contain a 'gui' package for gui libraries and you could  
extend that from 3th-party code I'd not use that convention in PyObjC  
because its package structure explicitly mirrors that of the  
Objective-C libraries it wraps.

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

How would that be more nasty than picking libraries to be included in  
the standard library?   A sanctioned library list would be a level  
between the standard library and random 3th-party code, basicly to  
avoid tying the release cycle of "obviously useful" software to that  
of python itself.

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

There's nothing wrong with .pth files per-se and I use them  
regularly. The juckyness is in .pth files that contain lines that  
start with 'import', those can do very scary things such as hot- 
patching the standard library during python startup. That's something  
I don't like to see in production code.

Ronald