Python 3.1 released

Not really, no. There are two things going on here.

First, many people seem to have a different view of the Python 3.0 migration process, when compared to what's been discussed and planned for by the Python development team. Put simply, nobody who actually works on developing Python expected that this would be a quick transition, and mostly they seemed to expect (and plan for) large projects taking at least a couple years to get to the point of running only on 3.x. That's why there will be a Python 2.7, and possibly a Python 2.8.

The other thing is simply that many end users can't do a quick jump to 3.0 installations and will be pretty upset if they lose new releases of software as a result. So "we're jumping to 3.0, too bad if you can't" isn't an attitude we can take. And, honestly, most of the operating-system vendors aren't going to be there with packaged 3.x Python and packaged 3.x libraries anyway.

So what we're doing is a process of deprecation: one Python version per release. Django 1.1 will be the last release to officially support Python 2.3, Django 1.2 will be the last to support Python 2.4, and so on until we hit Django 1.4 (hopefully) sometime next year. At that point we'll only officially be supporting 2.6 and newer in the 2.x series, distros will have had time to catch up, major installations will have had time to lay out upgrade plans and we'll be at a place where a 3.x port is far simpler to undertake.

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.