Why Do Projects Continue To Support Old Python Releases? 432
On Planet Python, Gregory Szorc asks why many projects continue to support Python releases prior to 2.7, when they are all EOLed (2.4 in 2008, 2.5 in 2011, and 2.6 last October), and Python 2.7 provides a clear upgrade path to Python 3. Quoting: "I think maintainers of Python projects should seriously consider dropping support for Python 2.6 and below. Are there really that many people on systems that don't have Python 2.7 easily available? Why are we Python developers inflicting so much pain on ourselves to support antiquated Python releases? As a data point, I successfully transitioned Firefox's build system from requiring Python 2.5+ to 2.7.3+ and it was relatively pain free."
Shortly after posting, other developers responded with their reasons for using older Python releases. First, Rob Galanakis of CCP (EVE Online) explains the difficulties involved in upgrading a mature commercial project embedding Python. Nathan Froyd adds "I think this list of reasons to upgrade misses the larger point in providing software for other people: You do not get to tell your users what to do. ... Maybe those users don’t have sufficient control over their working environments to install a new version of Python. ... Maybe those users rely on certain APIs only available in older versions of Python and don’t wish to take an indeterminate amount of time to rewrite (retest, recertify, etc. etc.) their software. ... Maybe those users are just rationally lazy and don’t want to deal with downloading, configuring, and installing a new version of Python, plus dealing with inevitable fallout, when the old version has worked Just Fine for everything else."
It's simple, its Redhat (Score:2, Informative)
Get Redhat to upgrade their version of Python, then the developers will use it. Until then if you want to write portable code, you ignore the newer features.
RedHat (Score:5, Informative)
The Python version included with RHEL 6 (that's the very latest version): 2.6
The Python version included with RHEL 5 (still widely used): 2.4
Thank them for forcing us to keep supporting old versions.
Blame Jython (Score:5, Informative)
I think a large part of it is due to the convenience of Jython, which makes it really easy to embed Python directly into a Java application as a user scripting engine that doesn't require explicit installation or configuration by the user. I'd go so far as to say that Jython is probably 99% of the reason WHY so many Java apps that support scripting do it via Python instead of some other language.
Jython only supports 2.x syntax.
There IS a way to bind a Python interpreter to Java so it can exchange objects directly (py4j), but it still requires separate installation of Python, with all the usual things that can go wrong (and frequently do, at least under Windows), like environment variables, path definitions, etc.
There's also IronPython, which is another 2.x-only Python that enjoys lots of "automatic" mindshare from Windows developers because it presents itself as the "official Microsoft-blessed .Net CLR Python" for Windows, and everyone remembers that a decade ago, Activestate Perl was the de-facto Perl for anyone running Windows (and eventually, the defacto Perl, period). It's basically abandonware at this point, but ActiveState doesn't go out of its way to make it obvious.
That said, I'd put most of the blame/credit for 2.x on the non-existence of "Jython 3".
Re:Offline side-by-side Python (Score:2, Informative)
You can: python virtualenv
Re:python sucks (Score:5, Informative)
If you are upgrading Python without so much as reading about what 3.x is and how it's different from 2.x, you're probably not qualified to be handling such an upgrade.
3.x was explicitly declared as a new language with breaking changes all around, so as to get rid of legacy cruft. This information was widely disseminated through all official channels - documentation, mailing lists, changelogs etc - and carried over on unofficial ones, like textbooks. That's precisely why all Linux distros out there install 3.x and 2.x side by side, and don't treat one as an update to another.
If your Linux distro silently re-symlinked /usr/bin/python to python3 when you installed the latter, then your Linux distro is broken - you should complain to its maintainers. If you installed it manually, then you have only yourself to blame.
And, getting back on topic, this all has nothing to do with 2.6 -> 2.7 transition, where the language is the same and backwards-compatible.
Re:Turn the question in the right direction (Score:5, Informative)
If we're talking about 2.4/5/6 -> 2.7 migration, then the question does not apply, because there's no "older dialect" - it's the same language, albeit with a few minor additions. There are no major breaking changes there. The problem is that you can't be sure that any of the minor changes do not somehow break your program, especially if it relies on something that was never a hard guarantee, and so you need to retest on the new Python version before you can officially declare it supported. This is no different from Java, for example.
If we're talking about 2.x -> 3.x, then the break is by design. Python 3 is simply a new language, which disposes with a lot of cruft that accumulated over the years in Python 2 (remember, we're talking about something that's 20 years old at this point). It makes it much better for writing new code, but also requires that you port old code, and places an additional burden on library developers to support both (at least for as long as 2.x remains popular).
Re:Turn the question in the right direction (Score:4, Informative)
Is this some kind of joke? Python's use of syntactically-significant whitespace is not in the same league as all the issues PHP has. [veekun.com]