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/)