I think it's crazy that they are only now talking about dropping support for Python 2.4 which came out in 2004 and has been replaced by Python 2.5 in 2006.
So only now they are moving from depending on 8 years old technology to depending on 6 years old technology.
The reason for this is probably the proliferation of really old versions in the default installation of still supported OSes like RHEL. Worse: Due to the fact that these distros largely depend on the Python installation they came with, it's likely that admins are reluctant to touch anything python related on the system.
Compare this to ruby/rails where the common practice is to treat system ruby as a hands-off thing: Usually, the deployment payload just includes its own ruby (using rvm or rbenv). This allows for much less conservative minimum requirements.
Being forced to constantly target way outdated software during development is really annoying and kills motivation as you are always reminded that if only you could update, you would be spared re-implementing feature x or you could use much more expressive code while implementing feature y.
And don't get me started on PH-4.x is good enough-P.
It is perfectly possible to use a deployment-specific version of Python, just like it is with Ruby. But there are organizations where using old technology is (unfortunately) the status quo. This means Django gives you the possibility of still running it in these environments. Hell, there's loads of companies using older versions of Windows and IE. Is it optimal? No, but that's something bureaucracy tends to do.
I am not trying to say Django is a better framework better for making this decision, but it is a decision that makes sense in the Python context, which is careful about breaking backwards compatibility. There's no reason to stop a developer who has that choice to work with Python 2.7 though (this is actually recommended in the FAQ). There is no need to touch the system's Python to do that.
Python 2.4 seem to still be a version you can find on "recent" system, like CentOS 5. So it made sense to be compatible with it, don't you think ? And RoR was conservatively still working with ruby 1.8 too...
I know not of any equivalent of rbenv for python, but I've not looked after, so here we are.
I wonder why more people don't realize this. Fact is, there are those who have no other option at their day jobs then to deploy to "ancient" systems for one reason or another, developers often do not have a say in the matter. It's good that these useful frameworks are willing to support the real world for as long as they can.
Virtualenv is now on the ascendancy but it wasn't always like this and there were many people who had workflows based on different tools including zc.buildout (for example). Virtualenv has gone from an up-and-comer to a top-dog over the last 4.5 years.
Django core devs have tried to be hands-off on dev-op issues perhaps to a fault.
So only now they are moving from depending on 8 years old technology to depending on 6 years old technology.
The reason for this is probably the proliferation of really old versions in the default installation of still supported OSes like RHEL. Worse: Due to the fact that these distros largely depend on the Python installation they came with, it's likely that admins are reluctant to touch anything python related on the system.
Compare this to ruby/rails where the common practice is to treat system ruby as a hands-off thing: Usually, the deployment payload just includes its own ruby (using rvm or rbenv). This allows for much less conservative minimum requirements.
Being forced to constantly target way outdated software during development is really annoying and kills motivation as you are always reminded that if only you could update, you would be spared re-implementing feature x or you could use much more expressive code while implementing feature y.
And don't get me started on PH-4.x is good enough-P.