Great blog post btw but I've had this in production (python2.4 and
python2.5) for almost a full year with no problems. We just have our
applications explicitly request python2.4 or python2.5 in the shebang. We
also did something similar for another application using the alternatives
system with %ifarch magic and %preun/%post scripts in the spec. It is
doable. Even managing /usr/bin/python using alternatives is *doable* if you
decide it is the right thing for your use case.
However for general purpose distro with finite resources I agree with you
completely. With production code that is tested in a limited environment
(read %packages --nobase in the ks) you should use whatever makes the most
sense. For my stuff, python2.4 lacks needed features. Each environment is
unique and neither is wrong.
Redhat not making python > 2.4 available in RHEL has caused some
environments to move away from RHEL/CentOS. It is one of the disturbing
reasons you'll see some of the ruby shops or newer django ponies websites
be powered by Ubuntu, Debian, or even Fedora.