[Python-Dev] python package

Guido van Rossum guido@python.org
Fri, 12 Jul 2002 13:36:38 -0400


> Guido van Rossum wrote:
> > I have thought some more about the idea of moving the entire stdlib
> > into a package named "python" and I reject the idea.
> > 
> > Think of the impact the change would have on the tutorial.
> > 
> > Think of the amount of needless changes to perfectly working code it
> > would entail.
> > 
> > If you want to avoid 3rd party module/package names to be invalidated
> > by additions to the standard library, you might just as well introduce
> > a "nonstd" package into which all 3rd party extensions must be placed.
> > This at least doesn't require people who don't use 3rd party code to
> > change their programs.

[MAL]
> Uhm, the point I was trying to make was to provide a long
> running upgrade path from the current situation (everthing is
> top-level) to the single package structure.

And my suggestion of a "nonstd" toplevel package had the same goal. :-)

> It is fairly easy to move from 'import os' to 'from python import os',
> but I understand that people will not want to do this until
> Python 3.
> 
> I was not suggesting to start breaking code by enforcing this
> strategy in some way, I just though it would be a good idea
> to start providing means to work with the single python package
> approach now to make the transition less painful in Python 3.

Two problems.  First, your proposal has lots of practical warts that I
already pointed out; your suggestion to fix one of them by making all
the old names stubs would require a massive set of changes to the CVS
repository.  Second, I don't think a 'python' toplevel package is the
right solution.

> > Maybe we should create a standard package hierarchy; Eric Raymond once
> > started working on such a proposal but I have discouraged him because
> > I think it would cause too much upheaval.  But for Python 3 I would
> > consider it.
> 
> That's what I was targetting :-)

Then please think about a proper solution rather than proposing
something whose only virtue seems to be that you can implement a poor
approximation of it in two lines.

--Guido van Rossum (home page: http://www.python.org/~guido/)