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."
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.
When developing, it's important to aim for the lowest support level. If all my customers are running offline RHEL 4, I'm stuck with python 2.3.
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?
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.
CentOS
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.
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."
If all my customers are running offline RHEL 4, I'm stuck with python 2.3.
How do you deliver an application to your offline users? And why can't you deliver an up-to-date side-by-side version of Python along with it?
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.
If it ain't broke don't fix it. I've run into that where a developer hoes to a new version of something and as a result what used to work fine now has problems. When the developer says 'I can fix that...' I tell them just to roll it back. Unless there is some new feature that makes upgrading useful there is no reason to run the risk of problems. Users don't care about the underlying technology as long as it gets the job done with a minimum of fuss.
I'm a consultant - I convert gibberish into cash-flow.
Why doesn't the new version of Python interpreter support older dialects ?
(source)
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
You could try porting your 2.4 scripts to 2.7, justifying it to your boss as a security measure to stay on a version of Python that will remain supported for the foreseeable future. That should involve very little change to your code. Then gradually shift the program to use those parts of Python 3 syntax that Python 2.7 supports through from __future__ statements, such as Unicode strings, print() as a function, and the like.
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.
Python 2.7 just works. Sure, it's a nightmare past a certain scale point. But until you get into the dregs of OO it really is executable pseudocode.
Python 3 is some other language that lost that property.
The big problem is that we don't ship languages with telemetry that reports when they fail to work. So things that are completely obvious to outsiders never make it to inner circles. Not that I can really see any way for Python 3 to mend its errors.
Also, to be realistic, you don't earn any money upgrading your existing software to the latest platform.
It's all fine and dandy to switch over to a new version of python. But unless we can justify it to our client, it ain't gonna happen. The client just isn't going to go for it unless they see some measurable/provable benefit to switching. From their point of view it works, and we'd better damn well not touch it. Unfortunately, the codebase has grown over the years, and sloppy developers have come and gone, leaving the rest of us with a brittle codebase that has very little code-coverage. This is most certainly NOT an ideal scenario when it comes to upgrading, as there are too many unknowns. And that's assuming we could get the client's permission, because yes, the code belongs to them.
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.
since the authors of python don't do proper unit and regression test and maintain backward compatibility, the 2.4, 2.5, 2.6 and 2.7 ARE DIFFERENT LANGUAGES! Its past time for open source wares (including the LInux kernel ABI) to get some maturity already in the realm of backwards compatibility, open source could go more places if it had that.
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".
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.
Another is the fact that some Python libraries use C modules (as opposed to using pure-Python code that uses ctypes to interact with shared libraries), and some users under Windows may not own a copy of the appropriate version of Visual Studio to recompile the module.
This particular aspect actually makes it easier to use more recent Python versions on Windows, not the other way around. Case in point: if you use 3.3, then your C extensions have to be built with VS 2010 compiler. If you use 2.7, they have to be built with VS 2008. Now, VC++ 2010 Express is still available as a download, and works just fine so long as you don't need to build 64-bit binaries. VC++ 2008 Express is also available, but only as a direct download link; the landing page (with the information about the file, "Download" button etc) is gone - you need to know where it is, or google for it to find it. And previous Python versions require VS 2005, which is even harder to obtain.
It's actually quite a headache in practice, because 2.7 is still more widely used, and people do keep running into problems trying to easy_install or pip install binary packages and getting those compile errors, and don't know where to go get the compiler.
Windows 8 says hello.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Sounds like you did it wrong. Why didn't you just rename the binaries?
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.
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??????
Secure messaging: http://quickmsg.vreeken.net/
Why are we Python developers inflicting so much pain on ourselves to support antiquated Python releases?
If I were a Python developer, instead of Python user, and there was a lot of pain supporting old Pythons, I'd just stop supporting them (instead of whining.) Older versions of Python only receive bug fixes. People who are still using an older version evidently are happy with it, bugs included. So, Python developers should fix old bugs if it's painless, or not if it's painful.
About the only exception I can think of is security problems: if a security flaw in an old version is suddenly revealed, it should be fixed by Python developers if at all possible. Then again, if that becomes too much trouble for Python developers, they can just (politely) say "if this bug really is a problem for you, you should just pay the pain yourself by upgrading to a newer version where we've fixed it."
Another clear exception is that the last 2.x version, 2.7, should have its bugs fixed into the foreseeable future because so many of us still prefer 2.x. Then again, I would have already switched to 3.x if a 2.7 didn't (already and into the foreseeable future) work just fine for everything I need Python for.
Python has a well-defined versioning scheme for interpreters which is documented in detail. In particular, it requires that python2 is a symlink to some version of Python 2.x, and python3 is a symlink to some version of Python 3.x; authors of Python code should author their scripts correspondingly. If someone wrote a 3.x script that starts with #!/usr/bin/python, then they are the problem, and you should whack them with a stick until they fix that.
Also note that this spec requires that python be the same as python2 until further notice, which will happen in 2015 at its earliest. So, again, if you or your distro symlinks python to python3, then that distro is breaking things.
As a user of a package written in Python, you are, of course, not at fault. But it's not a fault of Python language & interpreter developers, either - as you can see, they were well aware of the problem, and came up with a working solution. They can't really help it if distros (which are, ultimately, responsible for installing Python on your system) don't follow that solution, or if app developers who use such distros write bad code.
But, furthermore, Python 3.0 violates this principle as well: If there was one way to do it in 2.x, that way should continue to be the only way to do it in 3.0.
I think they should just admit it was a mistake and deprecate Python3. AFAIK many of its features have been backported to 2.7 anyway. Let's face it, if a major revision of a very popular language has been out for 5 years, and it's still not that widely used, there is something wrong with the new revision.
So prior to 02-Mar-2011, people using say python 2.5.2 (released in 2008) were not being "informed" to write their code using /usr/bin/python2, and so all that old code is now "improper" according to a spec released *3 years* after the code was written.
Any code written prior to the release of that PEP would be using #!/usr/bin/python, and the spec requires it to be a synonym for python2 for now, and at least for 2 more years (realistically, that change is probably going to be postponed for much longer). So someone using Python 2.5.2 in 2008, assuming they wrote the proper shebang, and assuming that the distro (which has no excuse for not following the PEP today) did things properly, will work fine.
The problem that OP described was someone writing a script that requires Python 3.x, but using #!/usr/bin/python. Now I'll grant you that 3.0 was released in 2009, before the PEP, so there is some possibility that someone had a valid excuse - but in practice, given the slow uptake of 3.x, it is extremely unlikely that you'd run into a package that was originally written for 3.0 but not 2.7, and that hasn't since been updated for 3.1+.
In any case, the symlinks are implemented by a particular distro. If that distro follows the PEP, then it's the job of package maintainers to ensure that the packages they provide have the corresponding shebangs. If the distro doesn't follow the PEP and do silly things like symlinking python to python3, then it's also their responsibility to ensure that any packaged Python software uses shebangs that match their convention (by patching the sources if necessary).
Also, note that the PEP basically documented what well-behaved distros were doing since the release of 3.0. It's not really a long one, and that's because what it says is basic common sense.
In which case, one might ask - if the new 'standard' (post 02-Mar-2011) is to use /usr/bin/python3, why would the symlink *ever* change (2015 or after even)?
The idea with that PEP is that apps should try to be specific about the version of Python that they want, but that "python" with no version specifier should be whatever is the most convenient to the user, which, at some point in 3.x adoption, would become 3.x rather than 2.x. Ideally it should have been unspecified from the get go, but because there was no clear versioning scheme for binaries before that, we're stuck with python==python2 until Python 2.x dies completely. The 2015 date is obviously overly optimistic, but then that's why it's not a hard date, just an estimate. Still, at some point, 2.x will not be in use anywhere, and then we can change the link. Apps should still use python3, though, on the grounds that there may be a python4 eventually.
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.
Sig Battery depleted. Reverting to safe mode.
Which is why COBOL will probably out live Python. Stability.
putting the 'B' in LGBTQ+
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.
Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
I love most things about python but there is something supremely arrogant about waving your hand and saying, sorry but we broke all your code. I hear all kinds of very well thought out arguments involving unicode and whatnot; but there are dozens of other languages that didn't break backward compatibility and have added all kinds of fundamentals such as ascii to unicode.
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).
That too, alive and kicking. BTW the last two versions, '08 and '03, are nice as the compilers give support for F77 while adding in OO and parallel programming functionality.
putting the 'B' in LGBTQ+