Why Do Projects Continue To Support Old Python Releases?

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."

Comments

Wrong question

[sjames]

Let's say I have something in python that was developed on python 2.5 and is in maintenance now. The correct question is why would I demand python 2.7 suddenly? Wouldn't that be kinda bone headed of me?

Why should I do extra work with the express purpose of making my software more demanding in it's requirements?

Because it works.

[Animats]

Many Linux distros in wide use still come with Python 2.6 as the stock Python. If you have some little program that needs to be portable, you write for Python 2.6 and test on 2.6 and 2.7.

People aren't converting to Python 3 for the same reason Perl users aren't converting to Perl 6 - it's different and incompatible. Many third party Python 2.x packages were never ported to Python 3. Some were replaced by new packages with different APIs, which means rewriting code and finding out what's broken in the new packages. Newly written programs tend to be written for Python 3, but much old stuff will never be ported.

Re:People don't upgrade

[Anonymous Coward]

There are lots of people that have installed python (or had it installed), but not as many that are willing to upgrade their python installation to the latest version. The jump to python 3.0 is a little tricky because some code is not compatible (which is why we still have 2.x) so there's lots of software that would break if people upgrade.

This.

My job, like most jobs, isn't to code in Python. It's to process data, and Python (be it 2.4, 2.7, or 3.0) just happens to be one of many tools that I use to process said data.

The fact that some developer might have built what he believes to be a better version of a Python interpreter than the one that ran my code is immaterial. I've got better things to do with my time than rewrite, re-test, and recertify known-good code.

If changing the first line of my script to #!/usr/local/bin/pythoninterpreterforbusinesscriticalstuff isn't elegant enough for your tastes, that's the Python devs' problem, not mine.

(If you think I'm annoying to Python devs, wait'll you see the grudge I have for Javashit frameworks and webdevs, who seem fixated on the concept that using HTML5 and Javashit is somehow more important than cross-browser compatibility, and that "cross-browser compatibility" means "all browsers will render it this week, and this week only, because the standard itself is a moving target! Who would want to display static HTML on a browser more than a week old?")

Turn the question in the right direction

[Meeni]

Why doesn't the new version of Python interpreter support older dialects ?

Re:When upgrades break code

[fyngyrz]

The changes from Python 2.5 to 2.7 are likely to be much less pa

Why should I accept any pain at all? How about if I just don't upgrade, and my stuff doesn't break, and I continue on making new things? Isn't that more sensible on every possible level?

Re:When upgrades break code

[smash]

Exactly that. Nobody cares if your new version is 10% faster, or has new feature X. If someone is using your language for something serious in the real world, and your upgrade BREAKS CODE, then all bets are off.

Even if the time and effort (in the real world, money, essentially) is spent to "fix" the project to work with the new version, all prior testing is essentially worthless, and the developer can't "trust" the code is correct and bug free any more until they've had sufficient time and testing to be comfortable with it.

This problem is endemic in open source unfortunately, and not just for developers - constant UI change, application deprecation/replacement, etc. Every time you change something significantly, there's a real cost to any person using it, even if your software is free. Even if they decide not to use it any more - they need to find a replacement and re-learn how to use the replacement.

I'm not saying "never change anything". But more work needs to be put into shims, switches, etc. to enable backwards compatible behaviour if possible - even if it is not enabled by default.