
Python 2.7.18, the last release of Python 2 - vishnu_ks
https://pythoninsider.blogspot.com/2020/04/python-2718-last-release-of-python-2.html
======
xscott
For those with Python 2 baselines that aren't (or will never be) ported, PyPy
will support version 2 basically forever [0]. PyPy supports a huge number (but
not all) of Python packages, including numpy [1]. Moreover, PyPy is
significantly faster in many cases [2], and for the numerical types of things
I like to write [3], it's amazingly faster.

    
    
        > time pypy mandel.py > pypy.pgm
        seconds: 0.318101
    
        real        0m0.426s
        user        0m0.396s
        sys         0m0.013s
    
        > time python2 mandel.py > python2.pgm
        seconds: 30.141954
    
        real        0m30.156s
        user        0m30.136s
        sys         0m0.003s
    

That's just a silly Mandelbrot example, but for numerical algorithms like this
PyPy is nearly 100 times faster than Python2, and that includes startup cost
for the JIT!

I'm not in any way associated with the PyPy project, but I can't help but
believe a sane world would've moved from Python to PyPy in the same way
everything moved from Brandon Eich's original JavaScript interpreter to the
modern JIT ones like V8.

[0] [https://doc.pypy.org/en/latest/faq.html#how-long-will-
pypy-s...](https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-support-
python2)

[1] [http://packages.pypy.org/](http://packages.pypy.org/)

[2] [https://speed.pypy.org/](https://speed.pypy.org/)

[3] [https://godbolt.org/z/J9Xwp6](https://godbolt.org/z/J9Xwp6)

~~~
orangecat
_I can 't help but believe a sane world would've moved from Python to PyPy_

Yes, and this is my fundamental complaint with the Python 3 transition. It
took probably millions of engineer-hours, and the result was better Unicode
support and a handful of minor features most of which could have been added to
Python 2 just as easily. I suspect most users would gladly have traded those
benefits for a 10x performance improvement.

~~~
scoot_718
> and the result was better Unicode support

Different Unicode support. And worse bytes support.

What could previously be done using python -c "..." is now long, horrible and
ugly.

~~~
mehrdadn
> Different Unicode support. And worse bytes support.

I feel like you're the first person I've seen on the planet to echo my
sentiments on these. I expect a lot of people will jump here to tell you
you're wrong like they have to me, so just wanted to let you know I've felt
exactly these pains and agree with you.

~~~
harikb
I am hoping this is in agreement. py2’s flexibility to handle utf8 bytes
without fuss is amazing. Then people come up with all kind of purity reasons
to make it more complicated.

~~~
raverbashing
> py2’s flexibility to handle utf8 bytes without fuss is amazing

Without fuzz? No, sorry, it was anything but.

First of all it would default encoding to "ASCII". Have any whiff of non-
explicitly handled UTF-8 and it would just go bang at the worse time possible.

That was a stupid decision

"Oh but there was setdefaultencoding" Yeah here's the first result for that
[https://stackoverflow.com/questions/3828723/why-should-we-
no...](https://stackoverflow.com/questions/3828723/why-should-we-not-use-sys-
setdefaultencodingutf-8-in-a-py-script)

So no, Python2 way of dealing with Unicode was the most annoying way possible,
because hey who needs anything but ASCII right?

~~~
pdonis
_> Python2 way of dealing with Unicode was the most annoying way possible_

The part about defaulting to ASCII is annoying, yes. And using
sys.setdefaultencoding to change the default would still be annoying, yes. The
reason for that is that _any_ default encoding will be annoying whenever the
actual encoding when the program is running doesn't match the default.

The correct way to fix this problem is to _not have a default encoding at
all_. Don't try to auto-detect encodings; don't try to guess encodings. Force
_every_ encode and decode operation to explicitly specify an encoding. That
way the issue of what the encoding is, how to detect it, etc., is handled in
the right place-- _in the code of the particular application that needs to use
Unicode_. It should _not_ be handled in a language runtime or a standard
library, precisely because there is no way for a language runtime or a library
to properly deal with all use cases of all applications.

What Python 3 did, instead, was to change the rules of default encodings and
auto-detection/guessing of encodings, so that they were nicer to some use
cases, and even more annoying than before to others.

------
jillesvangurp
Python is currently one of the most successful languages out there. Most of
the growth at this point is coming from python 3. So, from that point of view,
it's been a huge success.

If at this point you are still stuck on 2.7; you probably don't care a lot
about updates in any case; including point releases. It's been well over a
decade since it was made clear that this was going to end. So, IMHO the impact
to remaining 2.7 users is minimal. They were in any case extremely
conservative updating and are probably also running lots of other outdated
stuff like Red Hat / Ubuntu versions that long dropped out of LTS, etc. That's
fine and valid but at this point you shouldn't be surprised that you are on
your own. If you didn't plan for this, that's on you.

From a security point of view that just means you probably don't want to run
unprotected 2.7 servers running e.g. a web server. But otherwise it's fine if
you shield it a bit. Lots of python is more about other types of jobs where
the impact of security vulnerabilities is much less.

And, I'm sure that if there's demand, somebody might actually step up to do
the occasional patch release if it is really needed. This has also happened in
the Java world where several companies provide support for openjdk 6, 7, and 8
where Oracle no longer supports that (v8 stopped getting public updates
already; you can still pay for some extended support but that too is being
ramped down). I imagine, e.g. Red Hat might step up here as they seem to have
continued to ship this for quite long and their LTS cycles might out run the
python 2.7 cut off date.

------
wiremine
This isn't a knock per Perl, but looking back, it's really interesting to see
how the two communities handled their respective transitions: Python 2 to
Python 3, and Perl 5 to Perl 6 (now called raku [1])

I say it isn't a knock because I think they were equally fine with the goals:
Perl was looking to make a bold break towards an unknown future [2], and
Python wanted a very slow and sustainable migration.

I'm glad to see Python 3 go mainstream, I'm glad that Python 2 succeeded so
well, and I'm glad there are segments of computer science that still throw
mugs and aim for the moon.

[1] [http://blogs.perl.org/users/ovid/2019/10/larry-has-
approved-...](http://blogs.perl.org/users/ovid/2019/10/larry-has-approved-
renaming-perl-6-to-raku.html)

[2]
[https://www.nntp.perl.org/group/perl.packrats/2002/07/msg3.h...](https://www.nntp.perl.org/group/perl.packrats/2002/07/msg3.html)

~~~
donio
You have it backwards. Perl 6/Raku is a completely new language, the mistake
there was to call it "Perl". Perl5 on the other hand has handled its evolution
much more gently than Python 2 -> 3 did.

~~~
arunix
There's more to it than that. Looking at its early history [1], it is clear
that Perl6 was conceived/intended to be the next version of Perl after Perl5
e.g.

 _First, Perl will support multiple syntaxes that map onto a single semantic
model. Second, that single semantic model will in turn map to multiple
platforms._

 _Multiple syntaxes sound like an evil thing, but they 're really necessary
for the evolution of the language. To some extent we already have a multi-
syntax model in Perl 5; every time you use a pragma or module, you are warping
the language you're using. As long as it's clear from the declarations at the
top of the module which version of the language you're using, this causes
little problem._

There were even plans for a translator [2] similar to Python's 2to3 tool

 _Larry Wall and others are already working on a Perl 5 to Perl 6 translator,
which will be able to translate (most) Perl 5 source code to the equivalent
Perl 6 syntax._

 _In addition, Perl 6 will provide a "Perl 5 compatibility mode", allowing the
compiler to directly execute any code that it recognizes as being written in
Perl 5._

[1]
[https://raku.org/archive/doc/design/apo/A01.html](https://raku.org/archive/doc/design/apo/A01.html)

[2] [https://raku.org/archive/faq.html](https://raku.org/archive/faq.html)

~~~
lizmat
Those were the plans. In the meantime, Perl 6 has been renamed to Raku
([https://raku.org](https://raku.org) using the #rakulang tag on social
media).

Integrating Perl code in Raku can be done with the excellent Inline::Perl5
module
([https://modules.raku.org/dist/Inline::Perl5:cpan:NINE](https://modules.raku.org/dist/Inline::Perl5:cpan:NINE)).
In fact, that efficiency of that module basically killed the "parse Perl code
in Raku" project.

------
csande17
If you're interested in what actually changed in this update, the release
notes are here:
[https://github.com/python/cpython/blob/2.7/Misc/NEWS.d/2.7.1...](https://github.com/python/cpython/blob/2.7/Misc/NEWS.d/2.7.18rc1.rst)

------
MattGaiser
Still know a heck of a lot of people using it. Even know one researcher using
it for a new project.

It will be decades before the final Python 2 program goes offline.

~~~
contravariant
Does anyone know what the main reason is for not updating from python 2? I'm
genuinely curious as I don't really know any modules that won't work under
Python 3 and I can't really come up with any other blocking changes that would
make upgrading that hard.

~~~
jefft255
Lot’s of code is simply unmaintained. The guy that wrote it is gone, it’s
still running fine so nobody is touching it. Businesses don’t want to take the
risk and spend the money to upgrade it. Maybe you don’t realize the insane
amount of code that is in this state!!

~~~
6gvONxR4sf7o
In some ways that's the whole point of code. You want to get to forget about
it doing all these things without you.

~~~
takeda
If that's the case then 2.7.18 will continue working and probably it is a bad
idea to port it. A lot of work for minimum gain.

But if you actively changing the code, the maintenance will get more and more
expensive. With packages dropping python 2 support if you discover a bug in
one of your dependencies and fix is in package that no longer work on python 2
you'll need to backport the fix (and maintain your fork) or migrate your code.

------
linsomniac
We've switched off Python 2, but I really miss it. For a glorious several
years we were done with "production has Python X.Y, but the code needs X.Z"
and always chasing the latest minor version on LTS OS releases.

But now we're back on that treadmill...

~~~
brianwawok
How long does python upgrading take you? I think Python 3.7 to 3.8 was change
my docker version and push to CI... 5 minutes later it told me all tests
passed and I deployed to production??

~~~
mywittyname
I upgraded from 3.7 to 3.8 and found out they removed a function in the time
package required by crypto.

I do strongly feel that removing functions from the core library is a huge no-
no for point releases.

~~~
xxpor
You're supposed to pay attention to DeprecationWarnings.

~~~
MattGaiser
The problem is that the entire ecosystem needs to pay attention to such
warnings and it doesn't happen. As a result, these changes end up breaking
code in places the program authors never touched.

~~~
xxpor
That's true in one respect, but you as an end user can use them to know not to
upgrade before your deps have changed what they need to.

~~~
scoot_718
What? You upgrade your dependencies when there's a feature or improvement you
need. Not because they don't have some warnings. Who cares?

The old version you implicitly claim is better isn't, it just doesn't have the
warnings from their dependencies in place yet.

~~~
xxpor
I mean, if you're going to upgrade your python version, you should check your
logs to see if you have had any DWs recently. If you have, upgrade your deps
before upgrading python. If theres no new version available, you can't upgrade
python yet.

------
amenod
I still occasionally mistype `print s`.

RIP, python2, you will be missed. And a big thank you to all the contributers
who have kept it alive for so long!

~~~
Andrew_nenakhov
I still feel very wrong whenever I have to use print(), it was so much better
without ()

~~~
scoot_718
Agreed. It was so less painful to add and remove for debugging. Which is it's
only real use-case.

~~~
amenod
Yes - it is incredible how big a deal this is. I never would have thought a
few characters would mean so much to me. Ah well... :)

------
jimbob45
Is this the most infamous failure of a version upgrade ever in software
history?

~~~
zerkten
How is it a failure? When they were talking about Python 3 at PyCon 2008 and
2009, it was expected that the migration would take this long. Folks knew
migrating would be long and hard, and that the approach would need to be
revised.

It's only relatively recently that Python 3 passed a certain threshold that
made deprecation of Python 2 something that could actually be executed upon.
Had the growth been slower in the last five years I think the timeline would
have been different.

If I was going to critique Python "failures" I think the bigger target for me
would be the integration of async concepts into the platform and language.
This could have been handled more smoothly and with better community cohesion,
but most HNers only have a superficial understanding, i.e the GIL is bad and
Python can't compete with Go.

~~~
pseudalopex
The migration succeeded but the original plan didn't. People were supposed to
write Python 2 and generate Python 3.[1] What worked was making it possible to
have a single code base.

[1] [http://python-
notes.curiousefficiency.org/en/latest/python3/...](http://python-
notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#what-
other-changes-have-occurred-that-simplify-migration)

~~~
guitarbill
Agreed, all successful migrations I've seen started early and consistently
used `from __future__` and python-future to write compatible code over a few
years. This incremental approach almost made it trivial.

------
hypewatch
Python 2 had a great run but python 3 is more than ready for prime time. It
was pretty bad for a while but since 3.6 it’s been awesome!

~~~
takeda
Agree, actually it started being usable since 3.3 (and each following version
was better than last one), but 3.6 was when there was no longer anything that
python 2 was better at.

------
talentedcoin
Finally. Please let it die.

~~~
cellularmitosis
I just don't understand this sentiment. If some stranger wants to continue
using Python 2, why does that bother you?

Why did I not see this sentiment for C89 vs C99 for example?

~~~
yjftsjthsd-h
If a stranger wants to run _anything_ on their system, alone, never touching
anything else and never coming into contact, whatever. But I very much look
forward to a world where "Python" == "Python 3" precisely _because_ it keeps
impacting me. If I use a package that continues to use python2, I have to keep
a python2 installation on my system (complete with some set of modules).
Meanwhile, I can use the very latest, 100% maintained GCC or Clang to compile
any C standard version, so I don't think that's a good comparison.

~~~
a1369209993
> Meanwhile, I can use the very latest, 100% maintained GCC or Clang to
> compile any C standard version, so I don't think that's a good comparison.

So it's PSF's fault for not providing a -std=py2 option? I guess that's a
sensible way to look at it.

~~~
yjftsjthsd-h
I would hesitate to call them at fault per se, but yes I think if such an
option has been provided, particularly at a fine-grained level so that modules
could be moved over piecemeal, we would not have had nearly as much difficulty
with this transition. On the one hand, removing some of the pressure would
have meant that the old versions stayed around longer, but if the system
genuinely works and doesn't hold up the evolution of the overall project, I'm
not sure that I see a problem with that.

------
Qub3d
My personal thoughts on the matter aside, here is an informative post from
Brett Cannon on why the Python 2/3 split happened:

[https://snarky.ca/why-python-3-exists/](https://snarky.ca/why-
python-3-exists/)

~~~
loeg
That's what happened to fork the language, but really glosses on the "why."
Paraphrased: "People were too lazy about using the unicode type and bytes
type, so we forced all string constants to be unicode." I think there is some
cognitive dissonance between thinking this fixes lazy programmers and
expecting codebases to be rewritten in the new language. (I.e., by who? Those
same programmers too lazy to use the unicode type?)

Also, all the world wasn't unicode at the time and still isn't (unfortunately,
IMO, but still the case). We still have customers using various non-Unicode
encodings and not all characters have a 1:1 encoding/decoding round-trip
through Unicode.

~~~
pseudalopex
The article does say people get lazy or performance hungry but the theme of
that section is people making mistakes.

The part about Unicode is about how much Python 2 code accidentally only
handled ASCII. Python 2 requires handling other encodings as bytes anyway.

------
The_Colonel
I'm curious if there's going to be some community supported fork.

Software using Python 2.7 won't magically disappear and I believe there is
going to be a demand after fixes.

(I know about Tauthon but I don't think it applies here ...)

~~~
acdha
I think it's really unlikely because the primary reason people are still on
Python 2 is that they don't have development time to upgrade. If they had
enough time to support a community fork, they could just upgrade to Python 3
and spend the saved developer hours on something more important to their
projects.

~~~
The_Colonel
Collectively support maintenance of Python is much less work (and less risk)
than to port all existing production Python 2 applications though.

~~~
acdha
The problem is distribution: this might be true for the entire world but the
time demands to start and maintain such an effort are larger than the cost of
updating all but the largest projects.

------
gonational
I love so much about Python 3.

Python 2 has paid the bills for over a decade, but I love writing Python 3.8
so much more. I even love the walrus operator. We’re in the process of
upgrading, finally.

------
yjftsjthsd-h
I thought the last release was already past; wasn't the python 2 series
supposed to have ended on January 1st? Or did I misunderstand that?

~~~
nomel
2.7.18 was the planned final production release [1]:

> As of January 1st, 2020 no new bug reports, fixes, or changes will be made
> to Python 2, and Python 2 is no longer supported. We have not yet released
> the few changes made between when we released Python 2.7.17 (on October
> 19th, 2019) and January 1st. As a service to the community, we will bundle
> those fixes (and only those fixes) and release a 2.7.18. We plan on doing
> that in April 2020

[1] Sunsetting Python 2: [https://www.python.org/doc/sunset-
python-2/](https://www.python.org/doc/sunset-python-2/)

[2] When is the last release of Python 2.7 coming out?: [http://python-
notes.curiousefficiency.org/en/latest/python3/...](http://python-
notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#when-
is-the-last-release-of-python-2-7-coming-out)

------
memco
Trying to click the release notes for it on
[https://www.python.org/downloads/](https://www.python.org/downloads/) seems
to do nothing. I'm working on legacy apps running on 2.7 so I'm eager to see
what's included.

~~~
wichert
As far as I can see this should be the list of changes:
[https://github.com/python/cpython/blob/v2.7.18/Misc/NEWS.d/2...](https://github.com/python/cpython/blob/v2.7.18/Misc/NEWS.d/2.7.18rc1.rst)

------
ghshephard
Has anyone seen a recent survey of which version of python developers are
starting projects with?

~~~
pensatoio
I start every project on the latest widely compatible release. atm, that's 3.7
or 3.8.

Once you're using containers, shared build tooling, and enforcing
linting/testing, the version you use doesn't matter as much, imo. Unless
you're using an advanced feature that's still developing (rare..only seen it a
few times), most projects can upgrade minor version with zero codebase
changes. Just lock a new environment, format code, and push to CI.

------
tempodox
Mac vim(1) still requires Python-2. I'm not holding my breath.

------
at_a_remove
I am still on Python 2 due to complex vendor reasons. Probably will be for a
couple more years. I wish folks were a little more understanding that edge
business cases exist that they might not have considered; it isn't all
greenfield development.

~~~
mixmastamyk
Free support for ten years! Doesn't get any better than that.

~~~
at_a_remove
Wish I could get pip running. That'd be nice.

------
otabdeveloper4
> Python 2.7.18, the "last" release of Python 2

Fix't it for ya.

------
phendrenad2
I expect many forks.

~~~
mrweasel
But none that are actually going to be maintained in any meaningful way.
Maintaining Python 2 is a huge job, which is also why the Python core team
can't do both 2 and 3 at the same time.

~~~
badsectoracula
Well, the team that maintains the fork wont need to do both 2 and 3 at the
same time either, just 2 :-P.

~~~
sigzero
No but they will have to sell the "it's not official Python 2" line.

------
tedunangst
And now for python 2.8. From somewhere, if not python.org.

~~~
tialaramex
Caring for dwindling groups of increasingly eccentric users sucks. That
doesn't mean nobody will do it, especially at first, and especially if there's
money in it, but don't expect such maintenance efforts to have much staying
power.

------
loeg
Perhaps, but only because the PSF wields the Python trademark to prevent
people who want to continue releasing the Python 2 language from doing so:

[https://github.com/naftaliharris/tauthon](https://github.com/naftaliharris/tauthon)

~~~
MiroF
Rightfully so - it would be incredibly confusing to have a third-party python
with the same name but maintained by a different group of people. There's no
"right" to the python name.

If you actually look at the issue discussing this, you can see that Guido is
being more than amenable and the responses are honestly verging on childish.

~~~
loeg
Sure, I agree generally (which is part of why forking the language under the
same name was a poor choice!). However, python.org has demonstrably zero
interest in the Python 2 language and CPython runtime. So they can both say
"see, there's no interest in community maintained Python 2" and also prevent
that community from organizing itself under the name everyone uses at the same
time.

IMO, Python 2 is a genericized trademark like Kleenex at this point.

~~~
greggyb
> IMO, Python 2 is a genericized trademark like Kleenex at this point.

Kleenex is often used to refer to facial tissue, regardless of manufacturer of
the facial tissue.

Python 2 is used to refer to one of the releases of the CPython 2 interpreter,
most often the latest release, with earlier releases typically referred to
with their first point (e.g. "2.6" as I've seen elsewhere in this thread).
People rarely refer to Pypy or Jython as "Python 2", at least in my
experience. They may refer to compatibility with a point release of the
official CPython.

For example, Pypy describes itself as with the following:

> PyPy implements Python 2.7.13 and 3.6.9. It supports all of the core
> language, passing the Python 2.7 test suite and most of the 3.6 test suite.

They're not saying PyPy _is_ Python 2, rather that it implements the
programming language represented by point release Python 2.7.13. Elsewhere,
they talk about compatibility with Python. Nowhere do the PyPy developers
refer to their product as "Python 2".

