Slashdot Mirror
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."
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?
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.
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.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
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?")
Why doesn't the new version of Python interpreter support older dialects ?
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.
The problem with upgrades is the developers don't take nearly enough care to ensure compatibility with existing software. For instance, I moved a Python script from an older machine (redhat 9) to an Ubuntu 12 system with a later 2.x series Python, and the script immediately bombed out. Turned out that I'd used "as" as a variable name, and it had become a reserved word in the interim. Elsewhere, I was adding ints to floats or vice-versa; now that produces an error. Somewhere, the behavior of "global" changed. I had a procedure written with global VariableName up front so the procedure could see a global switch. I handed the script to someone else, and they had to *remove* that to make it work.
I moved a large system depending on perl scripts (yes, I know, not Python, but the issues are identical) across the same machine pair and it was so broken under the new perl that it took me two months (and cost my client a great deal of money) to adequately debug and update it. From external module changes (use DBI) to how references to hashes were handled, it was one thing after another. What made me fume the entire time is that this stuff worked *perfectly* under redhat 9 with the earlier perl -- it really wasn't broken. Bloody perl was broken! Worse, I'd abandoned Perl for Python years ago, and my Perl skills were very rusty... that's tough when you're trying to work through tens of thousands of lines of sophisticated code. I truly regret every line of Perl I ever wrote, and cringe at the idea of having to revisit it for any reason at all, because Perl, whatever its true merits, is a language that I was destined to hate to my very $core;
This kind of thing makes me extremely unwilling to upgrade; for that matter, it can send me hunting for the old version to install in new machines, although that can present its own set of problems and requires at least some of a different skill set than programming that really leans more into system administration, which I am not in the least enthused about. For some strange reason, enjoying research on auroras does not automatically carry with it a predilection for meddling with OS environments.
This is all part of a larger gripe set I have where makers of languages and APIs break existing code in favor of new ideas. Here's my position: If you ship the language with X features, you have NO BUSINESS breaking ANY of those features. You have a new idea? Fine. Implement it as something completely new within the language or the API. If it's got new keywords, provide the programmer a switch to enable them -- words that were not reserved before may have crept into the user's namespace(s.) Never take a call out of an API. Never make an API call work differently. If you think you need to do that, then *I* think you need an entirely new API. If you even use the word "deprecated", I will burn you in effigy and spit on the ashes. Furthermore, if you do it right, you will NEVER need to say "end of life" because the most current version will still run the first code ever written for API or language 1.0; upgrades will actually be upgrades rather than incompatible replacements.
Windows got this very nearly right for a long time, then with XP, they began to break everything from window metrics to system calls. By the time Windows 7 rolled around, apps that worked perfectly looked like trash and worked even worse, and I tossed my Windows machine in the can both for development and as a user. Apple's guilty of this too, even going so far as to obsolete their own applications and feature-sets. One really irritating example of this is having bought Aperture 1, 2, and 3 for OSX 10.6, I bought a new camera, a Canon EOS 6D. Works *fabulous*, pretty much the first DSLR I've ever been actually satisfied with. Both Lightroom and Aperture required an update to read the RAW images. Lightroom upgrade went smoothly. The Aperture upgrade? Told me that in order to install the updated RAW support, I'd have to upgrade the OS. But 10.7 and later are not highly compatible upgrades, I have to support OSX
I've fallen off your lawn, and I can't get up.