I think the python people made a few choices which prevented some of the problems: 1) It is very clear which version trees will accept new language features vs

I think the python people made a few choices which prevented some of the problems: 1) It is very clear which version trees will accept new language features vs. libraries vs. bug fixes. 2.7.x for instance generally only gets bug fixes at this point. (although they sometimes but rarely break that rule). 2) There is a clear path for language changes via PEPs (Python Enhancement Proposals). These are similar to RFCs. 3) Virtualenv does not attempt to manage python versions. It instead manages which libraries are installed you point it an existing installation and it symlinks the interpreter to the virtual env folder. That interpreter simply appears before the usual one on the path. It is not as heavy weight as RVM or RBENV. In general it seems like virtualenv is much more flexible about the way it can work than the ruby versions are. It is fairly un-opinionated. 4) Python programs can be packaged as .debs and so forth without too much overhead and without using the python setuputils during installation. Installing the library basically amounts to copying some files around especially if any extensions are pre-built. (which they can be in a binary distribution). Since new python versions in the 1.5-2.x line are strongly backwards compatible shipping a newer interpreter doesn't usually cause headaches for the applications which use it and were written for a previous version. I have code which was written for the 2.2.x and it works fine with no modifications in the 2.7.x line.