There is so much legacy code written in Python 2 that I can't imagine someone isn't going to have a large enough need that they will backport TLS support. Am I missing something on why that wouldn't work?
The value proposition might be there if the alternative was a python 3 port, but if you're installing packages of pypi these days it's unlikely you're running python <2.6 and I'm not sure a Python 2.6 -> 2.7.9 upgrade is of comparable difficulty to adding TLS 1.2 support to python < 2.7.9.
I mean, I know there's some old versions of Red Hat and co knocking about with 2.4 but you're probably better off to use your system package manager for those these days.
In RHEL those old Python interpreters are available precisely via the system package manager. And they won't support you if you install Python from a 3rd party RPM as I understand.
Yes. There are people who value support for a fixed version for 10 or more years much more than they'd value "rolling" support for a "latest" version that they have to keep updating their apps for.
People who use RHEL this way do not keep any third-party packages up-to-date. If that means a decade on Django 1.2, well, they spend a decade on Django 1.2 -- Red Hat will backport security fixes into a Red-Hat-packaged Django 1.2.
It's not a 2.7 vs 3.x issue. There are minor versions of both that have TLS 1.2 support. The issue is making sure that the minor version installed on a system is linked against a library that supports TLS 1.2.
