[Python-3000] packages in the stdlib

[Brett Cannon]

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


Exactly; I wouldn't touch it.  Which is why I don't like this idea of having
third-party modules add themselves to some stdlib package.

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.


No, there is no problem.  If we stick with a flat stdlib this is what I
would push for.

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.


They are both nasty, and there is a reason why modules that have competitors
don't get added easily.  Look at all of the discussion it took to get
pysqlite added; it took two tries and a lot of emails to get that cleared.

-Brett

>
> > >
> > > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060601/45e00ef9/attachment.html