> Speaking as someone who uses Python day-to-day and occasionally worries > about compatibility across Python versions: yes, it would be really nice > if Python better supported multiple versions installed at the same time. > lib/python1.5, lib/python2.0, and lib/python2.1 just don't cut it: I > remember running 1.5.1, 1.5.2, and alpha/beta versions of 1.6 > simultaneously. I had to install each to a separate prefix, which was > ugly but workable. It would be nice if Python (and, yes, the Distutils > now) had better native support for multiple simultaneous versions. That was mostly because we were abusing the version numbering scheme to roll out feature releases with a micro version number (1.5.1, 1.5.2). We don't do that any more -- feature releases have a minor (middle) version number change. If you really need to distinguish Python 2.0 and 2.0.1 on the same system, you're a Python developer by definition. :-) > Speaking as the main perpetrator of the Distutils: AAUUGGHGHHHH!!!! > NOOOOO!!! Please, don't make me look at this stuff AGAIN!!!! > Aiiieeee!! BTW, Greg, there's this bug I've found in Distutils, but the margin of this email isn't wide enough to describe it. :-) > But seriously: I think I once attempted to convince Guido that a > revamped organization of the library directories would be a good idea, > and that the Distutils would be a good way to introduce that scheme. > Obviously, I didn't convince him, so we still have the same system. Which I think isn't so bad given that we now have a well-behaved versioning policy in place. > The one glimmer of good news is that the Distutils "install" command > is insanely flexible; if you can manage to wrap your head around the > 17,000 levels of indirection, it should be a simple matter of > changing a few hard-coded dictionaries (there are two for Unix, and > one each for Windows and Mac OS) to introduce a completely new > installation scheme. I probably had some expectation that someday > this discussion would open up again. > > BTW, I'm skeptical about keeping .py and .pyc code in a > non-Python-version-specific directory (ie. site-python). Debian's > bytecode-recompilation at installation time scheme sounds cool, but the > desire/need to have multiple Python versions available kind of nixes it. > Bummer. Yes, good point. Bytecode is generally not compatible between versions -- its specification is considered an internal detail of the implementation (again, it can't vary with a micro-version, but it can and usually does vary with the minor version number). > Oh yeah, another thing I vaguely recall from the pre-Distutils-0.1 era: > Guido doesn't (didn't?) like site-python and wanted to deprecate it. > Perhaps the above paragraph explains why. Indeed, /usr/local/lib/python<major>.<minor>/site-packages/ is where site packages should go. --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