Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why Do Projects Continue To Support Old Python Releases?

Unknown Lamer posted about 9 months ago | from the developers-vs-developers dept.

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

Sorry! There are no comments related to the filter you selected.

OS versions (1)

Anonymous Coward | about 9 months ago | (#45911735)

Some versions of Python don't work on some OSes, mostly those with not-so-sane threading systems. Not that any of this matters, as the OS I can think of off the top of my head with such issues are Win9x OSes or other niche OSes that don't get as many updates as one would like.

Re:OS versions (1)

Penguinisto (415985) | about 9 months ago | (#45912193)

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

People don't upgrade (2)

Ksevio (865461) | about 9 months ago | (#45911749)

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.

Offline side-by-side Python (2)

tepples (727027) | about 9 months ago | (#45911817)

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:Offline side-by-side Python (3, Insightful)

Anonymous Coward | about 9 months ago | (#45911975)

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:Offline side-by-side Python (2)

Ksevio (865461) | about 9 months ago | (#45911985)

Giving someone a standalone software package is different than upgrading a system package. Offline systems can be upgraded with a USB stick, but it's harder to do a system update that way.

Re:Offline side-by-side Python (2)

tepples (727027) | about 9 months ago | (#45912055)

Then make python2.7 "a standalone software package" installed along with your application.

Re:Offline side-by-side Python (0)

Anonymous Coward | about 9 months ago | (#45912135)

And have to be on the hook if the Python install breaks something? You're joking, right?

And that's assuming your customers would even allow it since it would be unsupported by RH.

Re:Offline side-by-side Python (1)

shutdown -p now (807394) | about 9 months ago | (#45912147)

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:Offline side-by-side Python (0)

Anonymous Coward | about 9 months ago | (#45912187)

Because such arrogance always precedes the very act in breaking things in ways unimagined by the "nothing can go wrong" guy. Simply sticking with system-installed Python means you never need to worry.

Re:Offline side-by-side Python (1)

shutdown -p now (807394) | about 9 months ago | (#45912241)

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:Offline side-by-side Python (1)

Penguinisto (415985) | about 9 months ago | (#45912233)

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:Offline side-by-side Python (2)

shutdown -p now (807394) | about 9 months ago | (#45912297)

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:Offline side-by-side Python (1)

RabidReindeer (2625839) | about 9 months ago | (#45912359)

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

Which has a certain appeal, but I doubt that users in general would go for it.

Re:Offline side-by-side Python (1)

shutdown -p now (807394) | about 9 months ago | (#45912385)

Python is like Java in that it isn't simply a single program, it's a complex web of programs, libraries and model classes.

Yes, and they can all live under a single directory, isolated from everything else. That's exactly how Python works on Windows out of the box (it also installs its main DLL into System32, but that is really unnecessary, and many Python distros don't do it - and don't even have installers at all, like WinPython).

Python is actually less magical than Java in that regard, since you can fully control what gets loaded from where if you host it yourself.

Re:Offline side-by-side Python (2, Informative)

Anonymous Coward | about 9 months ago | (#45912137)

You can: python virtualenv

Re:Offline side-by-side Python (1)

RabidReindeer (2625839) | about 9 months ago | (#45912315)

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 (5, Insightful)

Anonymous Coward | about 9 months ago | (#45911831)

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

This.

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

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

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

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

Re:People don't upgrade (0)

Anonymous Coward | about 9 months ago | (#45912081)

HTML5 isn't a standard. Yes, I know they keep calling it as such, but the very point of a standard is that it doesn't move. It may get new versions, but the single version is cast in stone. If it is a moving target, it is no standard, period.

Re:Not Python... (0)

Anonymous Coward | about 9 months ago | (#45912195)

Javascript is the language of the Internet!

Re:People don't upgrade (4, Interesting)

RabidReindeer (2625839) | about 9 months ago | (#45912391)

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

This.

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

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

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

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

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 (1)

Anonymous Coward | about 9 months ago | (#45911835)

I would say that some people can't upgrade, even if they wanted to.

I have access to two computing clusters, and both are extremely outdated (linux 2.4 and 2.6). On the second one, I reached a point, were I can't update some software, because that would require to update some essential parts of the system, but this is not possible without risking the stability of the machine.

In the case of python, I don't have this problem, yet. But who knows, what dependencies will show up in the future...

Re:People don't upgrade (1)

Bert64 (520050) | about 9 months ago | (#45912285)

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 old software? Old software is unlikely to properly support modern processors, suggesting you have a cluster of old processors... Compute clusters tend not to last all that long before they get dismantled, as its not economical in terms of performance/watt to keep a cluster of old hardware running.

Re:People don't upgrade (3)

Trepidity (597) | about 9 months ago | (#45911841)

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 (3, Interesting)

Darinbob (1142669) | about 9 months ago | (#45912291)

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.

Wrong question (5, Insightful)

sjames (1099) | about 9 months ago | (#45911765)

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 (1)

Anonymous Coward | about 9 months ago | (#45911913)

To add to the parent: I think it's completely wrongminded to expect people to "upgrade" to a new version of a language. (Java, I'm looking at you, goddammit.)

It's fine if you want to patch the runtime library and give the patch a version number after the 2nd decimal point, but don't ever expect people to "upgrade" to a new set of features just for the hell of it. Often the guy who wrote it is gone, and the people who depend on the tools cannot be bothered to even attempt to understand the problems that might be caused by a new version of the language / parser / interpreter.

tl;dr: If it aint' broke, don't fix it.

Re:Wrong question (2)

bobbied (2522392) | about 9 months ago | (#45911981)

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:Wrong question (2)

RabidReindeer (2625839) | about 9 months ago | (#45912421)

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 reputation can be maximized.

Don't wait for it to break.

Re:Wrong question (3, Insightful)

msauve (701917) | about 9 months ago | (#45911945)

The author, Gregory Szorc, seems confused about what "support" means. What he appears to be complaining about is "Why do projects continue to require old Python releases?" (e.g. he says "I successfully transitioned Firefox's build system from requiring Python 2.5+ to 2.7.3+)

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:Wrong question (1)

sjames (1099) | about 9 months ago | (#45912115)

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:Wrong question (0)

Anonymous Coward | about 9 months ago | (#45912433)

One thing I would like to add is that eventually (could be a decade?) it will be unusable for some reason and you have to jump several versions to update. These 'jumps' tend to be more painful than staying current. Not picking on python- this is for anything.

It's simple, its Redhat (2, Informative)

Anonymous Coward | about 9 months ago | (#45911773)

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 (2)

connor4312 (2608277) | about 9 months ago | (#45911775)

CentOS

Re:One Word (0)

Anonymous Coward | about 9 months ago | (#45911807)

CentOS

Ah! So instead of updating Python, we should change our OS.

ALrighty Then!

Re: One Word (0)

Anonymous Coward | about 9 months ago | (#45912109)

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.

Change = bugs (3, Insightful)

mveloso (325617) | about 9 months ago | (#45911785)

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. (5, Insightful)

Animats (122034) | about 9 months ago | (#45911803)

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:Because it works. (1)

StripedCow (776465) | about 9 months ago | (#45911919)

Indeed. A similar question would be why people aren't "upgrading" from Python to Java.
It's a different language. Period.

Re:Because it works. (2)

shutdown -p now (807394) | about 9 months ago | (#45912163)

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:Because it works. (0)

Anonymous Coward | about 9 months ago | (#45912199)

it's actually quite easy to write code that's valid and behaves identically on both.

The point is that it's equally easy to write code that _doesn't_ behave identically on both.

Re:Because it works. (1)

shutdown -p now (807394) | about 9 months ago | (#45912275)

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:Because it works. (1)

shutdown -p now (807394) | about 9 months ago | (#45912153)

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 (5, Informative)

SoftwareArtist (1472499) | about 9 months ago | (#45911811)

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:RedHat (1)

Trepidity (597) | about 9 months ago | (#45911863)

Debian stable was on older Pythons until recently also, but Debian 7.0 (released May 2013) now has 2.7 default.

The flip side... (1)

MetalliQaZ (539913) | about 9 months ago | (#45911823)

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... (4, Funny)

sconeu (64226) | about 9 months ago | (#45912395)

but I've never encountered a situation where an older version is more attractive in any way

Windows 8 says hello.

Hahahahaha (0)

Anonymous Coward | about 9 months ago | (#45911829)

ROTFLMAO.
Python thinks just because they declare EOL on 2.6 that millions of users around the world are going to jump to 2.7?
Can they guarantee that 2.7 is bug-for-bug compatible with 2.6? That everything in 2.6 is still in 2.7? Can you honestly see a Wall Street bank, a top-tier cancer hospital, or a world-class university blindly update to the newer version just cuz Python Project said so? And risk their systems _just_ _not_ _working_?
No? I didn't think so.

Unit tests (1)

tepples (727027) | about 9 months ago | (#45911941)

It's possible to update without updating blindly. If the 2.5/2.6 version still passes unit tests and the most critical acceptance tests under 2.7, then perhaps 2.7 can be rolled out across part of the company at a time, using each division as an acceptance test for the next.

They're already using Python 3.x. (0)

Anonymous Coward | about 9 months ago | (#45912317)

A Wall Street bank, a top-tier cancer hospital, or a world-class university would have upgraded to Python 3.x years ago. That's just what makes them the best. They don't wait for others to tell them what do to. They know what to do before anyone else does, and then they do it. That includes upgrading to Python 3.x early.

python sucks (-1)

pe1rxq (141710) | about 9 months ago | (#45911833)

Upgrading python is a real pain.
The different versions don't even implement the same language.
Last time I had to upgrade to 3 for one piece of software all other packages seized working... why? Because they started with '#!/usr/bin/python' which now pointed to version 3 instead of 2.5. I had to edit all of them to use /usr/bin/python2.5

On the other hand I don't expect much better from those who think whitespace is part of the language anyway....

Re:python sucks (5, Informative)

shutdown -p now (807394) | about 9 months ago | (#45912181)

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:python sucks (0)

Anonymous Coward | about 9 months ago | (#45912215)

And, if you've wrapped any of your c/c++ code in dll's, you'll have to recompile them for the new python version. :-|

Re:python sucks (1)

sandertje (1748324) | about 9 months ago | (#45912247)

It would probably have been less work to just change the default interpreter back to python 2.5, and edit only the 'one piece of software' that required python 3 to /usr/bin/python3

Umm...Maybe... (0)

Anonymous Coward | about 9 months ago | (#45911837)

...because we don't want to rewrite all our software?

In today's lesson, we learn why it's generally considered a bad move to do a "clean break" upgrade in a FOSS project.

Corporations can get away with forcing developers and customers to upgrade (Apple does it all the time), but that's usually risky. Microsoft has been known to actually put bugs back into their OS in order to ensure compatibility.

FOSS projects can't get away with it. We have a whole set of infrastructure scripts written in Python that would need a pretty major overhaul to go Python 3. I think that they all run in 2.4 (I'll have to check).

If it gets to the point that we can't run them anymore, then we'll have to rewrite them.

In something other than Python.

First try 2.4 to 2.7 (2)

tepples (727027) | about 9 months ago | (#45911915)

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.

Not surprising (3, Insightful)

redmid17 (1217076) | about 9 months ago | (#45911839)

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

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 (1)

tepples (727027) | about 9 months ago | (#45911843)

RHEL/CentOS isn't the only problem. There are versions of Ubuntu Server still in long-term support that still ship with outdated Python, such as Ubuntu 10.04 LTS that ships with Python 2.6. 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. For a long time, the official binaries of the MySQL database client module for Python for Windows didn't support anything newer than 2.5.

Re:Ubuntu and Windows (2)

shutdown -p now (807394) | about 9 months ago | (#45912227)

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.

Re:Python 2.5 - September 19, 2006 (0)

Anonymous Coward | about 9 months ago | (#45912287)

Python is dead end for MySQL database client module!

Incompatibility (1)

FedeTXF (456407) | about 9 months ago | (#45911851)

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 (2)

Registered Coward v2 (447531) | about 9 months ago | (#45911871)

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.

Turn the question in the right direction (5, Insightful)

Meeni (1815694) | about 9 months ago | (#45911883)

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

Re:Turn the question in the right direction (0)

Anonymous Coward | about 9 months ago | (#45912131)

don't ask the obvious - that would be asking too much of these panty waisted foot-tapping metrosexual urban Euro-worshipping geeks in this crowd

Re:Turn the question in the right direction (2)

umafuckit (2980809) | about 9 months ago | (#45912183)

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. :)

To The Top!!! Score: 5 The ONLY Logical Answer (0)

Anonymous Coward | about 9 months ago | (#45912221)

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

This. This is the right question!

Re:To The Top!!! Score: 5 The ONLY Logical Answer (0)

Anonymous Coward | about 9 months ago | (#45912335)

But, but, but unicode strings!!
But seriously, the changes in python 3 make for a more well defined software interface to the way python works.
Sure you could fix something by simply adding a new way to do something, but then you have to maintain both the new and old way.

Re:Turn the question in the right direction (2)

H0p313ss (811249) | about 9 months ago | (#45912251)

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:Turn the question in the right direction (1)

thetoadwarrior (1268702) | about 9 months ago | (#45912289)

And it's possibly the main reason or at least one of the reasons Windows provides such a poor experience compared to everything else.

Re:Turn the question in the right direction (1)

phorm (591458) | about 9 months ago | (#45912437)

Like my XP soundcards that don't work in Vista/7? My Vista devices that don't work in win8?
How about programs that require .NET [insert non-latest version here]?

Re:Turn the question in the right direction (4, Informative)

shutdown -p now (807394) | about 9 months ago | (#45912263)

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:Turn the question in the right direction (1)

Darinbob (1142669) | about 9 months ago | (#45912357)

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 (1)

silas_moeckel (234313) | about 9 months ago | (#45911893)

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 it must be useful (1)

dwheeler (321049) | about 9 months ago | (#45912411)

It's not complicated. It's simple. Upgrading a production system is a *big deal*, and in many places there is a long delay between updates. Enterprises will often pay big $$$ to NOT upgrade (other than security patches), because they want rock-solid stability much more than the latest hotness.

E.G., RHEL 5 and CentOS 5 are widely deployed, and will be used for some time to come as production systems. They only support older versions of Python2. Therefore, *useful* programs that need to run on these widely-used systems must be written to run on these older systems.

Because Python 3 still needs work (2)

Ichijo (607641) | about 9 months ago | (#45911905)

Python 3.x has no relation to Windows Unicode filename support... Also, Python 3.x has proven significantly slower in almost all benchmarks that matter to us, especially start-up time.

(source [selenic.com] )

Why? (0)

Anonymous Coward | about 9 months ago | (#45911929)

Why not?

Legacy Support (1)

pubwvj (1045960) | about 9 months ago | (#45911931)

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. (2)

Effugas (2378) | about 9 months ago | (#45911963)

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.

Re:It's because Python 3 is broken. (1)

nicolastheadept (930317) | about 9 months ago | (#45912043)

The question was never why not upgrade to Python 3. It was about why not stop supporting EOL versions of Python prior to 2.7

Re:It's because Python 3 is broken. (2, Insightful)

Anonymous Coward | about 9 months ago | (#45912311)

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:It's because Python 3 is broken. (2)

shutdown -p now (807394) | about 9 months ago | (#45912319)

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 is a character") as wrong.

Re:It's because Python 3 is broken. (0)

Anonymous Coward | about 9 months ago | (#45912403)

This....

Came here hoping someone else shared my viewpoint on this issue....

Might not have been so bad if they didn't cripple two nice features....

print a
No shift key needed, no sore pinky fingers. Now they want print(a). Bah.

print "Hello %s" % name
Now it's some stupid thing that requires me to call a "format()" function?!?!? I can always remember using % but I have to go google how to do it in python3 every time.

Lots of useful code for doing network coding is in 2.x because of the asn.1 library and friends are just lacking on 3.x.

  Python3 is not helping me to do anything other than give up two nice shorthand things I used every day in python 2.x

Because it costs money... (2, Insightful)

Anonymous Coward | about 9 months ago | (#45911973)

Also, to be realistic, you don't earn any money upgrading your existing software to the latest platform.

There is no point? (1)

viperidaenz (2515578) | about 9 months ago | (#45911997)

If you don't require features from Python 2.7, why drop support for older version?

Re:There is no point? (1)

shutdown -p now (807394) | about 9 months ago | (#45912333)

Because the older version can have bugs, and those bugs will never be fixed at this point as it is EOL'd?

Re:There is no point? (1)

viperidaenz (2515578) | about 9 months ago | (#45912435)

and if the bugs don't effect your application?

The Client (3, Insightful)

XcepticZP (1331217) | about 9 months ago | (#45911999)

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.

We did it! (1)

Impy the Impiuos Imp (442658) | about 9 months ago | (#45912015)

Congratulations, you were successful. If it isn't broke, hundreds of thousands of installations don't want to fix it.

Deveopler Blindness (2, Insightful)

Anonymous Coward | about 9 months ago | (#45912045)

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.

because the writers of the language blew it (2)

iggymanz (596061) | about 9 months ago | (#45912061)

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.

Re:because the writers of the language blew it (1)

Darinbob (1142669) | about 9 months ago | (#45912423)

Don't lump all open source in that arena. GCC does a good job of catching regression changes, but then it's a more mature product used in more critical situations than Python. GCC also has competitors, the language is standardized, and other advantages.

Which does point to an odd trend I see. People see a new language that's gaining popularity and then that language gets adopted for a new project solely on the "cool" factor. Except that the language turns out to not be well supported or maintained and in the long run the projects based on it will struggle.

Why 2.6? Why not 3.x? (-1)

Anonymous Coward | about 9 months ago | (#45912079)

It's been over 5 years. Why are you still on the 2.x line? Why are NEW PROJECTS still being made for 2.x? Stop being complete asshats and FUCKING UPDATE!

Re:Why 2.6? Why not 3.x? (0)

Anonymous Coward | about 9 months ago | (#45912157)

It's been over 5 years. Why are you still on the 2.x line? Why are NEW PROJECTS still being made for 2.x? Stop being complete asshats and FUCKING UPDATE!

Because the development staff are skilled and efficient with the 2.x line, but not the 3.x line. As such any new project will require an order of magnitude more time using the 3.x line, at a minimum.

Unless you can convince mgmt that it is a good thing to have all developers out for paid education for a week or series of weeks for a good class on all the new bits and pieces in 3.x, as well as all the 2.x pieces that are no longer supported in 3.x.

It all boils down to economics.. how much money are you willing to loose to get the next project done in 3.x.. for most companies.. that number is ZERO

Blame Jython (4, Informative)

Miamicanes (730264) | about 9 months ago | (#45912105)

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

Re:Blame Jython (1)

shutdown -p now (807394) | about 9 months ago | (#45912365)

I don't think that contributes much. Jython certainly has some userbase, including its use for embedded scripting, but it's really small compared to using Python as a language in its own right (for web apps, scientific computing, and for GUI on Linux). This is especially true since Java has had standardized embedded scripting APIs (javax.script) for many years now, and any implementation is required to provide JavaScript through it - so JS is the golden standard for Java application scripting, not Python. IronPython is a more lucrative proposition for scripting on .NET, especially now that DLR is a core part of CLR, and C# has "dynamic", ensuring smooth integration both ways - but it's still a minuscule user base.

By the way, IronPython is no longer an "official Microsoft-blessed Python" for Windows or anything else - it's not a Microsoft project anymore, hasn't been for a few years now. I don't think there's really such a thing as "official MS-blessed Python" at this point, but if you look at PTVS [codeplex.com] - which is an "official MS-blessed Python IDE for Windows" - then it actually works best with CPython.

python is... (0)

Anonymous Coward | about 9 months ago | (#45912173)

Because Python is a scripting language, and you don't get to decide the interpreter version.

Host application still uses Python 2.6 (0)

Anonymous Coward | about 9 months ago | (#45912239)

In visual effects and animation, many of the 2013 editions of animation applications that are scriptable (Maya, Nuke, Hiero, etc.) are still stuck on Python 2.6 (usually following Autodesk's lead). A few of the 2014 software editions now use Python 2.7, but studios rarely upgrade to the latest and greatest in the middle of a show. Lots of things can break, especially C++ plugins that might also be scriptable through a particular Python version.

In comparison with corporate Java usage (0)

Anonymous Coward | about 9 months ago | (#45912249)

.. its still very early to migrate to a newer version.

Last couple of years I've worked at shops still using WebSphere 6.1 (JDK 1.5 = September 30, 2004).
My current project involves an application on the 'new' platform, WebSphere 7.0 (JDK 1.6 = December 11, 2006) for
a rather big bank (top 500).

Just my 2 cents,

Lau

support is the wrong word (1)

Hussam Al-Tayeb (3423459) | about 9 months ago | (#45912261)

a lot of applications have simply not been ported from python 2.7 to python 3.x

Its why I hate using OSS solutions (0)

Anonymous Coward | about 9 months ago | (#45912325)

Here is our free whiz bang program....it just needs the half a dozen dependencies listed below, that will not all be maintained, and at least one will break the others regularly....you did want to spend your life as an unpaid programmer instead of working didn't you.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?