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."
People don't upgrade (Score:3)
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.
Offline side-by-side Python (Score:3)
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?
Re: (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.
Re: (Score:3)
Re: (Score:3)
Re: (Score:2)
Why would a Python install break something, if it's installed side by side with your app?
If you don't want to break the OS, don't touch /usr at all, it's as simple as that - and it has always been possible on Linux.
Re: (Score:2)
Why would a Python install break something, if it's installed side by side with your app?
...as long as everything you call script/daemon-wise reads "python27 /path/to/my/new_product.py" , sure.
Unless you want the sysadmins to love the idea of re-jiggering links. 'course, that might break dependent packages, other python bits running on the same box, etc.
Re: (Score:3)
Ideally, the sysadmins should not even be aware that you're using Python. The entry point should be a shell script that will spin up the appropriate Python interpreter from the directory that was bundled with the app, and that shell script is what's referenced from crontab, service scripts etc.
Re: (Score:2)
Python is like Java in that it isn't simply a single program, it's a complex web of programs, libraries and model classes.
Although Java was expressly designed to permit multiple versions to co-exist and even execute at the same time in the same system, I'm less certain that you can do that with Python. At least without at least doing a chroot or a VM. Which isn't so much making the affected app play well with other systems that use other Python versions as it is setting up the app in a little world of its o
Re: (Score:2)
You still haven't explained how one can break a system by copying a bunch of files to /opt/yourapp. Yes, there are techniques where truly "nothing can go wrong", within certain reasonable limits. Knowing and applying those techniques is part of the skill set in this industry. If absolutely everything could break everything else, we'd never get things done.
Sticking with system-installed Python means that you need to worry whenever that system decides to update the version of Python that it uses.
Re: (Score:3)
Sticking with system-installed Python means that you need to worry whenever that system decides to update the version of Python that it uses.
"That system" would never "[decide] to update the version of (whatever)" because RedHat provides guarantees of that.
If RedHat would start sending its RHEL users such updates, the next thing the users would do is to migrate to SuSE' SLES or CentOS.
Remember, not every upstream is as fsckd up as GNOME or Mozilla or Google. Even MSFT is much much more sensible in that regard.
Re: (Score:2, Informative)
You can: python virtualenv
Re: (Score:2)
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?
Anaconda - Red Hat's automated boot-time hardware configurator - is one of several critical RHEL components written in Python.
If you swapped out the Python that came with the system with a new, incompatible Python, chances are good that it break so hard it wouldn't even be able to boot up.
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?")
Re:People don't upgrade (Score:5, Interesting)
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?")
You should be working in Java. Or COBOL.
Most languages mutate enough that yes, keeping ahead of the bit rot is indeed as much the developer's job as coding it in the first place. The only exceptions are systems designed with the mainframe mindset that you code it and forget it for 3-4 decades. COBOL, because no one could really stand to muck with it, and Java because Sun put in deprecation mechanisms so that even really nasty old stuff will still be maintainable in an emergency.
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: (Score:3)
What do you mean, "most?" All the other commonly used languages -- C, C++, the various .NET languages, Java, etc. -- most certainly do not mutate like that! New versions come out, sure, but they're not so broken in design that programs written in different versions have trouble coexisting on the same system!
Re: (Score:3)
Requiring the developer to install the correct old version of the compiler toolchain in order to make a change is much more reasonable than requiring every user to install an old version of a runtime environment, especially when said runtime environment doesn't like coexisting with other versions of itself.
Plus, Microsoft sucks. Compiling a C89 program in GCC is only a command-line switch away...
Re:People don't upgrade (Score:4)
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.
That much is true, but I read this post as just calling for support for pre-2.7 Python to be dropped, not all of 2.x. Upgrading to 2.7 doesn't introduce the kind of incompatibility that upgrading to 3.0 does.
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:People don't upgrade (Score:4, Interesting)
The whole question of why users don't upgrade seems to be to be about making the developer's lives easier as opposed to the customers lives. But for my entire career I've had to support older releases I'd rather forget about, and it was taken as a normal and expected part of being a professional. It has only been relatively recent that developers start feeling peeved and annoyed at customers.
However if you make it easier for customers to upgrade, maintaining perfect backwards compatibility, the problem can go away. For security issues, then back-port the fixes to older releases. You're selling a product, probably selling product support, so start offering the customers some service.
Now I can understand with Python being an open source project that the devs who aren't getting paid just want to program for fun. That's the trap of adopting someone's pet project for production uses. But there are professional organizations who will offer paid support for open source projects.
Re: (Score:3)
Re: (Score:3)
Part of this means the developer should not be making changes that break existing code. At the very least save this for major version changes. This isn't about pissing money into the wind, but giving customer value for the money they already spent. Ie, python 2.7 should not break python 2.3 code, there's no reason for that to occur.
If customers figure out that older versions aren't supported and are left to rot away while devs work on the cool new stuff, then the customers will find other vendors to deal
Re: (Score:2)
You can build local copies of virtually everything, including the libc, into your own prefix so it won't affect anyone else (./configure --prefix=/home/user/blah etc)... The only thing you can't upgrade is the kernel.
Not that you should have to do this, as its very painful to maintain but it is at least possible.
Most userland apps should run just fine, even on the 2.4.x kernel providing you compile an appropriate set of libs for them.
On the other hand, what are you doing with a compute cluster running such
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?
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.
Re: (Score:2)
Exactly. I have yet to find a case where 2.7 won't run code written for 2.5.
There is a better case (over time) for adding 3.x compatibility so the 2.x line can eventually retire, but considering there are still new systems coming with 2.6, I suspect 2.7 will be with us for a while. Then again, it is mature and highly functional so I'm not so worried about that.
Re: (Score:3)
>He only said that he didn't want it to work with older versions, and that it was not a lot of work - i.e. it still took some amount of work - to make it not work with older versions
He doesn't say that at all. Really. It's not even remotely in the article. He talks about dropping support for Python 2.6. This isn't an action involving work! It means you no longer care if it doesn't work in Python 2.6.
Re: (Score:3)
tl;dr: If it aint' broke, don't fix it.
To that I would add, if it works, don't break it!
The problem here is that 3.0 is not exactly friendly to 2.x scripts. I'm not going to argue the virtues of 2.4 verses 3.0, but I am going to say that if you break something when you upgrade your interpreter, expect to support the previous version for a LONG time.
Re: (Score:3)
I wish people in IT would stop saying "If it ain't broke". That's almost as bad as "All You Have To Do Is..."
Computer systems don't decay in the literal sense. So in theory, once done, done forever.
Reality, however, is different. Virtually no system is so isolated that some external hardware, OS, language or other upgrade cannot break otherwise healthy unchanged software.
It will break. And according to Murphy, it's going to break at a time when the inconvenience, expense, and damage to your professional rep
Re: (Score:3)
If you wait long enough you can then just jump to whatever the latest and greatest language happens to be. In 20 or 30 years it may be harder to continue to use Python than t would be to jump to Psychedelic Giraffe, or whatever the hot new programming language will be.
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.
One Word (Score:2)
Re: (Score:3)
I worked at a company that used CentOS and they wouldn't upgrade Python for production environments because newer versions weren't certified to be stable.
Even though common sense says they are.
When core OS services are written in Python (and they are in CentOS/Red Hat), it doesn't matter how stable the newer releases are.
If they don't perform exactly identically, there's a real risk that the OS itself may malfunction.
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: (Score:2)
Indeed. A similar question would be why people aren't "upgrading" from Python to Java.
It's a different language. Period.
Re: (Score:3)
Python 2.x and 3.x are definitely much more similar than Python and Java, or even than Perl 5 and Perl 6. Especially when you look at 2.7 and 3.3 (where both versions had bits and pieces added to make syntax more uniform - like adding b"" literals to 2.7 and u"" literals to 3.3), it's actually quite easy to write code that's valid and behaves identically on both.
Re: (Score:2)
Sure, it is. You need to know what you're doing to pull that off. It's still a much better situation than Perl 5 vs 6.
Re: (Score:3)
On the parenthesis: It looks like it would have been possible to make the parser (or at least the command line input) parse "AB" into the same result "A(B)". Perhaps this conflicts with some part of Python syntax somewhere but I don't see it right now. This would then allow print to work as before, and would also make things like "help foo" typed on the command line work.
Strings however are a serious impediment to 3.0. You are blissfully ignoring the huge problem: a range of bytes can contain any arrangemen
Re: (Score:3)
On the parenthesis: It looks like it would have been possible to make the parser (or at least the command line input) parse "AB" into the same result "A(B)". Perhaps this conflicts with some part of Python syntax somewhere but I don't see it right now. This would then allow print to work as before, and would also make things like "help foo" typed on the command line work.
It wouldn't actually fix print as the differences are much more than that. 2.7 print had a lot of funky syntax in it - e.g. you could use >>stream as the first argument to print to a given stream rather than stdout, and then there's trailing-comma-meaning-no-newline (a la BASIC). I don't think these can be uniformly handled without treating print specially, and the whole point of the change was to stop doing so. I think it's a good thing, too - there's really no reason to single out print, and when te
Re: (Score:2)
Many Linux distros in wide use still come with Python 2.6 as the stock Python.
How many, actually? So far the only one that has been named explicitly is RHEL.
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.
Re: (Score:2)
Debian stable was on older Pythons until recently also, but Debian 7.0 (released May 2013) now has 2.7 default.
The flip side... (Score:2)
Maybe users don't want to upgrade, like Mr. Froyd says. But maybe they would upgrade if you gave them a reason to. I'm definitely not a large scale user, but I've never encountered a situation where an older version is more attractive in any way.
Re:The flip side... (Score:5, Funny)
Windows 8 says hello.
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.
Ubuntu and Windows (Score:2)
Re: (Score:3)
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 abou
Incompatibility (Score:2)
New Python versions come with incompatible changes. Very rarely you can grab code written for one version and run it completely unmodified on a newer version. This sucks and is made worse by third party APIs that also have to be modified.
It is hard to release new language versions and also keeping backward compatibility. Some languages do it better than others.
Simple (Score:3)
Turn the question in the right direction (Score:5, Insightful)
Why doesn't the new version of Python interpreter support older dialects ?
Re: (Score:3)
Why doesn't the new version of Python interpreter support older dialects ?
Not justifying it, but possibly it's to keep the code as homogenous as possible in the aid of readability. Like with the identing, Python likes to force you to do things its way, and its way is the only way. :)
Re: (Score:3)
Why doesn't the new version of Python interpreter support older dialects ?
Bingo.
Why has Microsoft dominates so much for so long? Backwards compatibility.
(Not the only reason, but a arguably the big one that nobody can compete with.)
(One day you'll get your day in the sun WINE...)
Re: (Score:2)
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: (Score:3)
Odd, that doesn't seem to have been a problem for many much older languages.
What, the accumulation of cruft? It has been a problem for all much older languages that are still being actively used, but especially those that are also actively evolving. Java is piles upon piles of cruft at this point, for example. PHP, even more so. C++, don't even get me started on that. C doesn't have that much, but only because it's a much smaller language in general; proportionally, it has just as much cruft as anyone else (think "register" and "auto").
And yes, those languages do in fact break thin
Re: (Score:3)
I don't consider Python perfect or ideal,
I can agree with that.
just reasonably good. At the very least, certainly better than PHP.
Not that. PHP's only real problems are inconsistent naming and parameter order. (Interestingly enough, a problem partially shared by python in spite of PEP 8) Unlike Python, it doesn't suffer from any serious design flaws.
Here's an example that you're undoubtedly tired of hearing about: Meaningful white space. It looks like just a matter of personal preference at first, but has far-reaching consequences. I've mentioned in the past how it makes some editors unusable and it makes mov
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]
Re: (Score:2)
Laziness? Lack of respect for users? Not understanding who the users actually are and what they do? Younger devs who've never dealt with backwards compatibility nightmares before?
Rhel 5 (Score:2)
Still ships with 2.4
Rhel 6 not much newer.
Lot of us with lots of production boxes want stable and fight to keep it that way. There is also the library issue many have not ported to 3.x or made major we broke things changes to do so.
Because Python 3 still needs work (Score:3)
(source [selenic.com])
Legacy Support (Score:2)
Because some people can't upgrade to the latest and greatest for a variety of reasons. Tone down your arrogance - its messing up your nose hair.
It's because Python 3 is broken. (Score:3)
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.
Re: (Score:2)
Re: (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: (Score:3)
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 often (though not always) indicates that the original codebase is written without much if any awareness of the existence of different text encodings, and will therefore handle anything other than ASCII or Latin-1 (or, if you're really lucky, UTF-8) wrong. Exposing that is a good thing. The whole point of changes around strings in Python 3 was to explicitly expose the various assumptions centered around "text is just a bunch of bytes" and "a bunch of bytes is always meaningful texts" (like "every byte i
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.
There is no point? (Score:2)
If you don't require features from Python 2.7, why drop support for older version?
Re: (Score:2)
Because the older version can have bugs, and those bugs will never be fixed at this point as it is EOL'd?
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
because the writers of the language blew it (Score:3)
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.
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".
Why is support for old versions even needed? (Score:3)
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.
First try 2.4 to 2.7 (Score:3)
Re: (Score:3)
We have a few applications written in zope. Zope was one of those classical python programs that needs a very specific set of libraries for each version of zope. Some of the required versions aren't even on the net any more according to google. At some point the Zope team split up and now the new zope won't do most of what the old zope was doing and the old zope has bugs and is a security risk and is now abandon-ware . So far we have hired 3 different python coders to "fix" the old applications yet none
Unit tests (Score:2)
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: (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: (Score:3)
Python has a well-defined versioning scheme for interpreters which is documented in detail [python.org]. 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
Re: (Score:3)
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
Re: (Score:3)
Sounds like you did it wrong. Why didn't you just rename the binaries?
Re: (Score:2)
Well, that and custom add-on code often blows up under 2.7 unless it's re-factored (or in some cases re-written), and nobody ever seems to want to do that...
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:OS versions (Score:4, Interesting)
Which is why COBOL will probably out live Python. Stability.
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: (Score:3)
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.
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).
When upgrades break code (Score:5, Interesting)
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
Re: (Score:3)
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.
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.
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: (Score:3)
Re: (Score:3)
True, but then why do we have this entire whiny slashdot article wondering why people support old Python versions?
The clear implication is that it is somehow the programmers fault for not re-writing the universe each time
python developers sneeze? It should be patently obvious that the fault lies with the Python Devs for failing
to bring their users along, and that some people, most people, just about all people, have something better
to do than rewrite systems every three years.
But you STILL have a maintenan
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: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: (Score:3)
this, and I am not sure how whomever decided the string/unicode changes in 3.x with no 2.x backwards compatibility couldn't figure out that it would be very unlikely that people would port all their code right away. This blog post I read a few days ago sums up some issues pretty well
http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ [pocoo.org]
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.
Re: (Score:3)
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.