What you refer to as a "big problem" and "holding back" of the evolution, I don't see at all in the same perspective. Its not imo an infrequent occurrence that

What you refer to as a "big problem" and "holding back" of the evolution, I don't see at all in the same perspective. Its not imo an infrequent occurrence that software authors decide to do things so differently in a new version, that it fundamentally breaks compatibility with the old way of doing things. Ie python 3 is something different from python 2; just like how in the C world a libXYZ.1.0 may have an entirely different api from a libXYZ.2.0, or how linux 2.6 differs from 2.4 for device driver writers etc; because the developers felt there was a compelling reason/opportunity to do things differently/better as the world moved forward. In all cases, authors of other 3rd party software somehow dependent on the above (ie python, the hypothetical libXYZ etc) must then decide when/if they will transition to the new way of doing things. And this in turn will have a knock-on effect on users of that 3rd party software, who in turn may suddenly have some further constraints imposed on them in terms of what they can and can't combine, what additional testing may be required etc. That is just the price of progress; and frankly I don't see that anything else (Ruby, .NET) is somehow immune to this ever happening. I build a lot of embedded systems that combine a variety of components, libraries etc, and there are forever dances around picking versions of things to get compatible dependencies, over the whole spectrum of technologies. There are also always degrees of freedom, ie sometimes you just have to use both the old and new versions to satisfy dependencies for other components, run things as separate executables and then stitch those together via an ipc mechanism. I don't think its realistic to think anyone's base technology might not ever change incompatibly; and so even though it might bring more work for a while, I don't see this change in python as anything so different from what we deal with anyway elsewhere, that it would merit me to consider for a moment replacing python with something else, either in the embedded environment or elsewhere. In fact I applaud the python developers for their courage to be able to walk away from old paradigms and cut old cruft. Maybe in looking at something like Ruby, right now you might feel a pythonista to be at a disadvantage to a rubyist if the latter is perceived as working with a more "stable" (unchanging) platform at this particular moment, and who's to say you're not justified in feeling so; but to my way of thinking it seems virtually assured that at some future point, Ruby will also undergo the same type of thing. (Or, as tends to happen to those technologies where developers cannot find the courage to walk away from the old, things stagnate and love withers away). Thus, I do not see this change holding back the evolution of python at all. In fact I would argue evolution of a technology is held back precisely when the developers thereof cannot bring themselves to do the necessary to replace the old by the new, for fear of inconveniencing everyone dependent on the old. Eventually that technology can no longer remain on par with the others without such qualms, and it dies.