> With the exception that we have control over the Python core > code while we don't over third party extensions, so providing > means to simplify the transition for the standard lib is easier > than trying to enforce your proposed 'nonstd' package. I think you could get a long way with minor changes along the lines of making site-packages a package itself. > > 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. > > Just testing waters here... there's no point in trying to > find a solution to something which is not regarded as problem > anyway. You started by claiming that there's a problem: expansion of the stdlib could conflict with 3rd party module/package names. I don't regard it as a problem that's so bad that we need to make big changes to solve it. If you still think a solution is desired, you could start by proposing a new standard package hierarchy. Then new standard modules could be placed in that new hierarchy rather than at the top level. I'm rejecting the proposal of a single top-level package named "python". --Guido van Rossum (home page: http://www.python.org/~guido/)
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