Guido van Rossum wrote: >>>Perhaps we could have some kind of category for distutils >>>packages which marks them as system add-ons vs. site add-ons. >> >>+1 -- this should definitely be up to the package author/packager, not >>the local admin. I once tried to convince Guido that the ability to >>occasionally upgrade standard library modules/packages would be a good >>thing, but he wasn't having it. Any change of heart, O Mighty BDFL? > > > Before I answer that, here's a question. Why do we think it's a good > idea to distribute upgrades as separate add-ons while we don't think > it's okay to distribute such upgrades with bugfix releases? The idea is to provide bugfixes for Python versions which are no longer being maintained. Of course, the effect would only show a few years ahead. > Doesn't > this just increase the variability of site configurations, and hence > version interaction hell? I don't think that core packages are any different than other third party packages: they are usually independent enough from the rest of the code that upgrades don't affect the workings of the other code using it. The internals are free to change, though, e.g. to accomodate bug fixes, etc. -- 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