Forgot your password?
typodupeerror
Python

Why Do Projects Continue To Support Old Python Releases? 432

Posted by Unknown Lamer
from the developers-vs-developers dept.
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."
This discussion has been archived. No new comments can be posted.

Why Do Projects Continue To Support Old Python Releases?

Comments Filter:
  • by Ksevio (865461) on Thursday January 09, 2014 @06:37PM (#45911749) Homepage
    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.
    • 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)

        by Anonymous Coward

        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.

      • by Ksevio (865461)
        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.
        • by tepples (727027)
          Then make python2.7 "a standalone software package" installed along with your application.
      • Re: (Score:2, Informative)

        by Anonymous Coward

        You can: python virtualenv

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

    • by Anonymous Coward on Thursday January 09, 2014 @06:51PM (#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?")

      • by RabidReindeer (2625839) on Thursday January 09, 2014 @07:53PM (#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.

        • by smash (1351) on Thursday January 09, 2014 @09:37PM (#45913149) Homepage Journal

          The only exceptions are systems designed with the mainframe mindset that you code it and forget it for 3-4 decades

          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.

        • Most languages mutate enough...

          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!

    • by Trepidity (597) <delirium-slashdo ... org minus author> on Thursday January 09, 2014 @06:51PM (#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.

      • by fyngyrz (762201) on Thursday January 09, 2014 @08:37PM (#45912687) Homepage Journal

        Upgrading to 2.7 doesn't introduce the kind of incompatibility that upgrading to 3.0 does.

        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?

    • by Darinbob (1142669) on Thursday January 09, 2014 @07:41PM (#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.

      • by smash (1351)
        Its not about making developer's lives easier. It is about not pissing money into the wind merely to maintain the status-quo. You think developer time is free? Even if it is un-paid, developer time wasted on re-writing working code is time that could be spent writing code to solve new problems instead. I.e., there is an opportunity cost.
        • by Darinbob (1142669)

          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

  • Wrong question (Score:5, Insightful)

    by sjames (1099) on Thursday January 09, 2014 @06:39PM (#45911765) Homepage

    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)

      by msauve (701917) on Thursday January 09, 2014 @07:01PM (#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.
      • by sjames (1099)

        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.

  • by Anonymous Coward

    Get Redhat to upgrade their version of Python, then the developers will use it. Until then if you want to write portable code, you ignore the newer features.

  • CentOS
  • Change = bugs (Score:4, Insightful)

    by mveloso (325617) on Thursday January 09, 2014 @06:42PM (#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. (Score:5, Insightful)

    by Animats (122034) on Thursday January 09, 2014 @06:46PM (#45911803) Homepage

    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.

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

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

    • 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)

    by SoftwareArtist (1472499) on Thursday January 09, 2014 @06:47PM (#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.

    • by Trepidity (597)

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

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

  • Not surprising (Score:4, Insightful)

    by redmid17 (1217076) on Thursday January 09, 2014 @06:51PM (#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.

  • 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 d
    • 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

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

  • by Registered Coward v2 (447531) on Thursday January 09, 2014 @06:54PM (#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.
  • by Meeni (1815694) on Thursday January 09, 2014 @06:55PM (#45911883)

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

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

    • by H0p313ss (811249)

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

      • And it's possibly the main reason or at least one of the reasons Windows provides such a poor experience compared to everything else.
    • by shutdown -p now (807394) on Thursday January 09, 2014 @07:37PM (#45912263) Journal

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

    • by Darinbob (1142669)

      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?

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

  • by Ichijo (607641) on Thursday January 09, 2014 @06:57PM (#45911905) Homepage Journal

    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])

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

  • by Effugas (2378) * on Thursday January 09, 2014 @07:02PM (#45911963) Homepage
    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.
    • 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: (Score:2, Insightful)

      by Anonymous Coward

      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.

    • 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

  • by Anonymous Coward

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

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

  • The Client (Score:4, Insightful)

    by XcepticZP (1331217) on Thursday January 09, 2014 @07:06PM (#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.
  • by Anonymous Coward

    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

  • by iggymanz (596061) on Thursday January 09, 2014 @07:12PM (#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.

  • Blame Jython (Score:5, Informative)

    by Miamicanes (730264) on Thursday January 09, 2014 @07:17PM (#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".

  • by TheloniousToady (3343045) on Thursday January 09, 2014 @08:40PM (#45912709)

    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.

Whoever dies with the most toys wins.

Working...