End of support for python 2.7?

Question

Is there a known date/timeframe when python 2.7 will not be supported any more in favor of python 3?

Solution 1

As of 13 Apr 2014, from http://hg.python.org/peps/rev/76d43e52d978 (PEP 373, Python 2.7 Release Schedule):

The End Of Life date (EOL, sunset date) for Python 2.7 has been moved five years into the future, to 2020. This decision was made to clarify the status of Python 2.7 and relieve worries for those users who cannot yet migrate to Python 3. See also PEP 466.

Solution 2

In May 2010, Word of God was that patchlevel releases for Python 2.7 will probably be made for at least 6 years.

So, maybe 2016, probably later.

Edit: Pushed back to 2020. See the revision to PEP 373, linked to in other answers.

Solution 3

Recently, that date has been updated to January 1, 2020.

see https://pythonclock.org/

Solution 4

you should read this carefully (ref : https://news.ycombinator.com/item?id=7582300 ):

There are a lot of comments here from people who aren't on the python-dev list and don't really understand what this diff actually means. The core developers are not required to maintain 2.7 post-2015, and most of them won't be involved in it. That part hasn't changed. What is happening is that Red Hat is preparing to cut a RHEL 7 release, which AFAIK depending on how much you pay them they support for 13 years. So they will need to figure out how to support 2.7 themselves at least through 2027. Here is where I am reading between the lines. RH are well within their right to fork Python and keep their maintenance patches to themselves and their customers (Python's not copyleft). But, they are nice guys and so maybe they are willing to upstream their changes at least for awhile if there is still a Python project willing to accept them. Again, this is my speculation based on the ML discussion, not what RH has actually said they will do. An analogy can be made to Rails LTS, a commercial fork of Rails 2.x that patio11 was involved in [0]. Inevitably somebody is going to step in to support 2.7, and so let's see what we can do to avoid a situation where the only way to keep running 2.7 is to subscribe to RHEL. Meanwhile, there are some large companies that use 2.7 extensively on Windows (e.g. Enthought, Anaconda) and the thinking goes that somebody can probably be found to produce a Windows installer once in awhile, assuming that Python.org will still host a download. So really what is happening here is not very exciting. The core committers aren't doing anything different than leaving the project as originally planned. What is happening is that they will leave the lights on in the source control repository and on the FTP server, so as to capture the free labor from people at large companies who have an interest in continuing to support 2.7. The alternative is that RH and other vendors create proprietary and expensive forks of Python 2.7. That may end up happening anyway, but it will take longer for your employer to notice you should stop contributing your patches back if binaries still appear on python.org and you don't have to ask IT to set up SCM and a bug tracker, etc.

Solution 5

This article says: “When 2.7 is released, the 2.x line will move into five years of a bug fix-only mode.”

So, as far as I see, Python 2.7 was the last 2.x feature-adding release, and though found bugs are going to be fixed (for some time), new features only go to 3.x releases.

View more solutions

Comments

[Lennart Regebro]

That article also claims Python 3 introduce Unicode, so I would take whatever it says with a grain of salt. But change "five year" to "at least five years" and it's correct.

[Silas Ray]

For anyone finding this answer in the future, as announced by the BDFL himself at PyCon 2014, 2.7 maintenance is extended to 2020 now.

[lowtech]

what a relief! hopefully python 3 will be dead by then or renamed into something like morella to stop confusion.

[ArtOfWarfare]

@lowtech - They may have moved on to Python 4 by then (possibly introducing new backwards incompatible changes), but I don't expect 3 to have died out. Based on how quickly 3 has been rising in popularity over the past few years, I expect the community will have more people using 3 than 2 by 2020. I'm still holding onto Python 2, though... not enough compelling changes to make the risk of jumping to 3. I import from future a lot, though.

[Collin Anderson]

Sometime around: 2020-07-03

[Stian OK]

@Basic Except it's not full of vulnerabilities.

[Basic]

@StianOK It's got its fair share: cvedetails.com/vulnerability-list/vendor_id-10210/…

[dhj]

@Basic welll... that share is pretty slim: 25 over all python versions (4% code exec): cvedetails.com/product/18230/Python-Python.html?vendor_id=10‌​210 vs php with 408 (27% code exec): cvedetails.com/product/128/PHP-PHP.html?vendor_id=74 or Java with 438 (3% code exec): cvedetails.com/product/19117/Oracle-JRE.html?vendor_id=93 ... So by "its fair share" you must have meant a "remarkably low share". Also, all but 3 of those vulnerabilities were also in vulnerabilities in a 3.x version and all up-to-date versions are fixed.

[Basic]

@dhj You're using PHP and the JRE as a security baseline? Java's security track record is so notorious, governments recommend against its use on consumer devices. PHP's manual still advocates SQL string concatenation. You're not setting the bar very high. You're also not factoring in usage/market share. Java and PHP have been widely used for decades. Python (while quite old) is nowhere near as widely used and so there's less chance for vulnerabilities to be found. In short, I'm happy with my choice of wording

[dhj]

@Basic do you have a better suggestion for a security baseline?

[Basic]

@dhj Yes... Not Java! Ok, that's unfair. Joking/flippancy aside, the honest answer is no, I don't. That's why I went with "fair share". There isn't a language out there that doesn't have known (and unknown) vulnerabilities. I'd say that as a general rule the more widely used a language us, the more known vulnerabilities there are, purely as a function of scrutiny aka usage/reward from exploiting. I'm not saying Python is worse than other languages from a security standpoint but it's no better either. The only real answer is to program defensively and have security in depth.

[Bhuro]

That date had been updated to 1st January, 2020 ..... check here pythonclock.org

[Gromski]

It's not "pointless" to EOL products, it's about resource allocation. Of course, since it's open source, it'll be around forever in its current form. But it won't be supported any longer. At least by the official maintainers. I'm not really sure what question you're answering here.

[Max]

The user asked how long there will be support for Python2.7. The user did not ask about support from official maintainers. With a project like this, with that many lines of code out there, in practice, there will be regular updates, backports and good support for Python2 forever, by non-maintainers. (I got carried away by my personal frustration about this whole Python3 thing, hence the "pointless").

[Phil]

I feel this comment is relevant. Tauthon is identical to Python 2.7 and seems like it will be supported for a while. So, it is worth mentioning.

[Max]

I have made the experience that younger programmers do not understand the power and efficiency that comes from guaranteeing backwards compatibility. I will never understand Guide van Rossum's decision to cause harm, more than tens of thousands of hours of wasted life, by intentionally breaking compatibility for no good benefit (neither performance nor readability).

[Tetragrammaton]

@Max Python 3 being not backwards-compatible is generally a good thing, actually. Python 3 rectifies some fundamental design flaws and redundancies in the language, and that should lead to more simple and elegant code. Despite that, many concerns about migration being this bad are unjustified and melodramatic. As of now, the most popular libraries have already migrated (see link ) and it's only getting better with dropping support in favor of Python 3.x. Nothing ever stays the same (otherwise nothing would progress). It's time for a change, we've had plenty of time.

[Max]

@Tetragrammaton: Please explain why not being compatible is a good thing. Please explain what the "fundamental flaw" would be. I've been working with Python full time over 15 years and I cannot see a major difference that is relevant for me. C stayed the same for 40 years and is still a major language and has not changed a lot. Javascript improved extremely over the years and is still backwards compatible. C++ is still backwards compatible with C. Windows 10 can still run Windows 3 programs. Our CPUs still run 8086 code from the 70s. We make progress every day, without breaking support.