Guido van Rossum wrote: >>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. This wouldn't work since in that case you'd have the problem of having to fix class names in e.g. pickles for objects which you don't know anything about. We do know about objects in the Python standard lib, so we could take care to have mechanisms like pickle deal with them properly. >>>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. I believe that the more Python grows (not only the core, but the complete set of available modules and packages in the Python universe), the less likely we are going to hit a problem. > 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". You've written that before, but you still haven't given any explanation of why a single package would be worse than a multi-level hierarchy of modules (e.g. grouped by application space). I think that simply moving to one package would cause less breakage and make the whole transition process much easier than having to tweak code into using some complicated multi-package structure. FWIW, I've been through all this with the mx packages and using a single new package caused the least amount of work. Even better: it turned out to be easy to provide backwards compatibility code so that applications still using the old layout continue to run, but start using the new structure in their pickles. No need to get heated, though. I just thought that it would be a good time to start thinking about this option again. -- 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