Django is in a very different situation because Python is central to all of its users, therefore it is reasonable to expect that they maintain a somewhat modern (released in the last 3 or 5 years, say) environment. When Python merely performs a subsidiary role, and your users may never use it themselves, it is far more important to support old versions.
I mentioned Django as a counterexample; the conversation seemed to be heading toward using the single specific example of Mongrel to demonstrate that there either is not a problem here or that it's not particularly serious.
Meanwhile, anyone who depends on Python for much more than a config-file parser knows what a genuine and large issue this is, and that "just write to the lowest common denominator" is not really a reasonable solution.
However your replies started with your response "That's simply unacceptable" to my "I'd very much like to know why it wasn't easier for him to simply write in Python 2.4" You mentioned (in this context actually OT) Django much later.
And I still don't know if he tried adjusting his already existing Python code to simply be backwards compatible -- he never mentions that, neither why that would be a problem in his particular case.
Regarding Django, see the other replies here about side-by-side installations, it's more than reasonable if you have something big which always runs, but not reasonable for a small config script used once.
My point is that the lowest common denominator is higher for users of something like Django because Python is a central component of what they do, thus it's reasonable to assume that they are not using an 8-year old Python environment.
Tell that to the many, many people I know who are using Django on RHEL. There's a reason why we just (as of Django 1.2) got around to dropping Python 2.3 support...
