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.
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. 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.
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 :-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/