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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4