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."
Wrong question (Score:5, Insightful)
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?
Change = bugs (Score:4, Insightful)
Change means bugs. Why would you want to disrupt your production system to fix bugs introduced in a new release? What benefit would there be to you?
The system is built, and it works. Don't touch it unless you have to, or unless it was designed to be upgradeable.
Because it works. (Score:5, Insightful)
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 (Score:5, Insightful)
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?")
Not surprising (Score:4, Insightful)
I'm just going to mirror what this guy said. There's a reason why IE6 was still around *years* after it should have been taken out back and shot. There's a lot of money dumped into these project and applications. I'd make every effort to encourage a transition, but those cost money and time.
Turn the question in the right direction (Score:5, Insightful)
Why doesn't the new version of Python interpreter support older dialects ?
Re:Wrong question (Score:4, Insightful)
What does he care if they support older releases, which in no way implies that they won't also work with newer releases. It's the maintainers of those projects who do the work, not him.
Because it costs money... (Score:2, Insightful)
Also, to be realistic, you don't earn any money upgrading your existing software to the latest platform.
Re:Offline side-by-side Python (Score:3, Insightful)
Because he doesn't want the support calls headache? Using the RH-provided Python makes it RH's responsibility to support rather than the ISV's.
The Client (Score:4, Insightful)
Deveopler Blindness (Score:2, Insightful)
The appropriate question is: Why should I re-write/replace/upgrade my software, that works perfectly fine(!) because some developer of the Python project decided to refactor/deprecate a function/break a feature or otherwise fiddle with the system.
Any software that runs properly today, should continue running long into the future. If it doesn't, if the langauge developers break my software, they are the issue.
From a user perspective, there is nothing I hate more than some app that suddenly needs a completely different version of Java than the one I'm running! My app ran on Java 1.6.1 through 20, but suddenly on 21 forward it doesn't work? Java/Oracle broke my app and is forcing me onto an upgrade treadmill which I have no genuine need to be on.
This is what I call developer blindness. They feel that they know better and that users or other developers are stupid for not embracing the idea that wheelSpinNG() is vasly superior to the now deprecated wheelSpin(). For all the Microsoft hate that goes on around here, they have historically done a fantastic job at maintaining backward compatibility. You seem to want to fail it.
Re:It's because Python 3 is broken. (Score:2, Insightful)
No really.
I took a pass at Python 3 a while back. The amount of hoops I needed to jump through, to deal with compilation errors around Unicode handling, was terrifying. It was simply a poor user experience.
That doesn't necessarily mean Python 3 is broken.
Lots of Python developers are discovering that they don't really understand how to do Unicode properly. Their code works under Python 2 (mostly by accident), but Python 3 calls BS and forces you to do it right.
Re:python sucks (Score:3, Insightful)
Bullshit.
All programs had '/usr/bin/python' set as their interpreter.
Some developpers asumed it would be python 2.5, the others assumed it would point to 3.0.
Why is it my fault (the user of a package) that python developpers make a mess of their versioning system?
They made a new and incompatible language and gave the interpreter the exact same name and you think I am not qualified??????
Re:People don't upgrade (Score:5, Insightful)
No, but it still introduces significant incompatibility -- things can and will break -- and so re-testing, re-coding, re-certifying... still required. Now, you have two choices:
a) Don't screw with the system, and everything continues to work just fine, no extra costs or problems are encountered, and everyone is happy except the cluetard who write TFA, who no one cares about anyway. Or:
b) You can upgrade, break everything, incur lots of costs, and everyone in every direction is pissed off except said cluetard.
Now, I ask you: what's obviously the best choice here?
Re:When upgrades break code (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Re:People don't upgrade (Score:5, Insightful)
You just described any serious application used in production in a real business, who's core industry is not "software development". Fucking around re-writing stuff costs money. Re-testing everything costs money. Fixing bugs costs money. Unless there's a REALLY good, real world fucking reason to be spending said money that will directly impact the business in question it is wasted money.
This is exactly the sort of thing many open source people don't seem to get: even if your software/development tools are FREE, pulling major compatibility-breaking changes costs real world people real world money. THIS is why Windows is so popular in the real world.
We know the security is inferior. We know the stability is often questionable. We know it costs money in purchase and/or ongoing licensing fees. BUT: you pretty much get a guarantee that any code written today will continue to run for at least 10 years (due to specific OS version support for that long) and likely a lot longer than that; due to API support normally extending even further. Re-writing shit just because the platform changed costs real world time and money.
Re:OS versions (Score:5, Insightful)
Just look at the time line:
(2.4 in 2008, 2.5 in 2011, and 2.6 last October),
Stop obsoleting code on a 3 year cycle and you wouldn't have so many stragglers.
Programming languages need stability and backward compatibility. You can't rebuild the world each time
someone decides to issue a point release. Handle it in the compiler.
Re:When upgrades break code (Score:5, Insightful)
Exactly.
Refuse to accept new release that don't support backward compatibility of existing code.
Every other sane programming language does this to the fullest extent possible.
Seems Python likes to just cut the cord.
Re:When upgrades break code (Score:5, Insightful)
That was probably going from Perl 4 to Perl 5. Going across a major release where many features have changed is going to cause problems with any language. The changes from Python 2.5 to 2.7 are likely to be much less pain.
not necessarily, in my experience one of the bigger issues is incompatible changes made in CPAN code: plenty of things change and it's not like you can say 'install from CPAN of 3 years ago'. If you write straight perl (i.e. no external modules) it's unusual for things to break badly, but if like most people you use CPAN modules you're at the mercy of each individual CPAN package mantainer
Re:OS versions (Score:4, Insightful)
Exactly. I'm pretty sure COBOL programs I wrote almost 30 years ago would still compile today. That code would be about the same age as the guy mentioned in the summary (5 years out of university btw) who is whining about supporting 3-5 year old code. Boo-hoo.
I'm pretty sure when the world ends the only thing left will be cockroaches and they will be using COBOL.
Re:OS versions (Score:5, Insightful)
I get this feeling that the core developers of Python have lost focus of what the typical developer wants. I see the same thing happening in C++ with templates. Templates aren't bad its just that the bulk of C++ developers are far more interested in the cool new iterating system in C++ than all the wonky template features that are added hourly. Luckily with C++ there has been no threats to break backward compatibility.
It is almost like these people are trying to impress some old CS professor instead of making their customers more productive.
But where the python people are playing with fire is that if a company has a massive codebase that is getting creaky and needs a huge Python porting effort that would probably be combined with a huge architecture refactor then that company might think, "we don't want to be forced to do this in the future, so what other language has been more version stable?" Or you might have a new IT head who has been pushing for his favorite language and will take advantage of this to switch. Python is awesome but there are other fish in the sea; and as we all know even good languages can fade (see PERL) and no so good languages take their place (PHP).
Re:When upgrades break code (Score:4, Insightful)
Very nice post! If I may summarize:
To paraphrase Robert Monroe: "Change is the only constant. Fast change is called revolution, slow change evolution."
The inexperienced young want change because of some cool new feature X, Y, and Z.
The experienced older want stability because they know the wisdom of "Don't fix what isn't broken!"
Businesses typically want stability because why would they pay someone again to re-write, refind bugs, re-test, and re-fix bugs, when the old version worked before?
The only reason to *really* change an API is because of security issues, aka how Microsoft "extended" legagy C API's to 'safe' versions such as: scanf vs scanf_s, etc.