
All Python versions less than 3.6 are now EOL - hprotagonist
https://devguide.python.org/#status-of-python-branches
======
epistasis
About every other month I have to help a biologist who has pulled down an
older program from Github debug why it broke in their data only to find that
they were trying to run in Python 3 instead of Python 2. These are people that
can write shell scripts, but don't program. It makes me aware of all the old
code out there that is not used super frequently, but still solves people's
problems, and would continue to if there hadn't been breaking changes.

As I write Python 3 now, I am less than impressed with the reasons for
breaking compatibility. I'm told that it was necessary for proper bug-free
Unicode code, but there's enough difficulty when using, say, gzip, and little
enough documentation about the "proper" way to handle Unicode that I doubt
that it will actually reduce Unicode-related bugs.

Python is still a great tool, but Python 3 really took the shine off for me.

~~~
donor20
Agreed completely.

There were so many routes forward that didn't involve breaking everything but
still would have allowed fewer unicode bugs (maybe). And they could have done
a lot more to make the transition easier if they wanted to - some of it was
just in your face type breakage to a prove a point without considering some
underlying use cases (a lot of internet protocols, headers etc still ASCII).

What is nuts to think about - if tweaking some unicode handling is worth
creating an incompatible version, what happens when some random python
developer has another itch to scratch that they consider so important it is
worth break a language over. The idea that these types of fixes require
breaking compatibility is absolutely insane if you want to address a larger /
longer term market.

Complain all you want about Microsoft, C etc. Even go of all languages
(because google has an otherwise terrible rep in this area!!). But some of
these languages and companies really do seem to be able to deliver or intend
to deliver longer term compatibility.

When businesses and lifetimes are measured in decades (not months) it is VERY
nice to build on stuff that has longer support horizons.

~~~
joshuamorton
Python 2.7 was supported for 9+ years, python 3 was released in 2008, with
development beginning before then. You had almost 15 years of warning from
initial announcement to eol. Python3 _predates_ golang.

> And they could have done a lot more to make the transition easier if they
> wanted to - some of it was just in your face type breakage to a prove a
> point without considering some underlying use case

Such as?

> (a lot of internet protocols headers etc still ASCII).

What do you mean here? Py3 correctly handles http headers encoded as ascii
bytes. Yes the decision to make http headers ascii bytes and not basically
anything else is bad in hindsight, but that ships sailed.

~~~
ornxka
>You had almost 15 years of warning from initial announcement to eol.

Why should I have to do labor to fix things that already work?

~~~
michaelmrose
Maintaining python2 and python3 forever in perpetuity wouldn't be free either.
Why should they provide free labor in perpetuity so that you need no provide
any?

In theory if there was sufficient need the entire community of python2 users
could collectively fund said support but I don't see how they can demand it
for free.

------
makecheck
It frustrates me that even now I regularly find out about some new thing being
written at work, only a few months old but already fairly widespread among
internal teams, and...oh, they chose Python 2.7. We not only have Python 3
available but _several_ versions of it, too.

Python 2 doesn’t _sound_ like an ancient, totally-different-language so people
just adopt it because it was the version on their laptop or something and
because it “works”. In reality, it’s inevitable that some major IT upgrade
will finally throw out that interpreter (or, the existing one will fail to
work for some obscure reason and no one will fix it because it’s
“unsupported”). And at _that_ time it will be non-trivial (to say the least)
to fix every affected script and the entire downstream dependency chain
because — as so many on HN know — Python 3 is a different language.

Any ideas on how to present this to management as the crisis that it should
be? It’s really quite a risk but it is hard to demonstrate the risk when
everything “works” so “well” right now.

~~~
jeffrallen
It's not a crisis. If Python 2.7 works, people will keep using it. The real
crisis is all the lost time dealing with porting to Python 3.

~~~
zamadatix
Middle English still works too doesn't mean it's not a problem to try to use
it for a new project. Everything has trade offs, both staying on the old AND
moving to the new. At some point everyone does move and managing the size of
that transitional tail well is part of running a business well. There is not a
one stop answer to the problem of when to migrate to the new and stop using
the old but "always bleeding edge" and "always what we started with" are
unlikely answers for most places.

------
Wowfunhappy
Up until the Coronavirus hit, I was a volunteer teacher at a Girls Who Code
club, where we used Python. I spent our very last class before the universe
collapsed introducing students to the concept of functions.

Once we'd finished going over some example programs, I asked the kids to
modify a quiz program they'd written previously with a different teacher. That
program used copy-pasted lines of code in order to ask multiple questions, and
I wanted the students to re-implement it with a single function instead. This
was a pretty challenging assignment—the kids had _never_ encountered functions
before today, and I was purposefully not quite telling them what to do, only
giving examples of functions used in other contexts. But one of the girls
managed to get it, and I was really proud of her.

Except her code wouldn't run because—I realized with horror—the original
program she'd done with the other teacher was actually python 2 code.

I am _so damn frustrated_ that this happened! I was trying so hard to make
these kids understand the concept of functions; I did _not_ want to explain
the differences between Python 2 and 3. It is, of course, primarily my fault—I
should have coordinated better with the other teacher—although in my defense,
we were both volunteers, and as it is I spent most of my Friday and Saturday
planning this lesson.

It also should just never have happened! I'm not aware of any other language
where this type of confusion is so common, and it really makes me wonder if
we'd be better off teaching something else. I'm not sure who is to blame for
the situation, but it really sucks, and I don't think it's going to go away
just because Python 2 is now technically EOL.

~~~
Xylakant
Ruby went through a similar period when transitioning from 1.8 to 1.9. Strings
learned about encoding, breaking most libs handling strings, some syntax was
added, some removed. It was possible to write 1.8 and 1.9 compatible code, but
it took some effort. However, the big players in the community, rails etc.
tackled that change head on. It was a point of pride for libraries to be 1.9
compatible. And everyone moved on. I’m always puzzled by how hard the python
community ist stuck on 2.x

~~~
pansa2
Python didn’t have a single big player like Rails to “lead the charge”.
Instead, its ecosystem is made up of many smaller libraries.

Because it’s not possible to run Python 2 and Python 3 code together, none of
those libraries could upgrade until its dependencies had done so. This just
led to everyone waiting for everyone else.

~~~
xapata
Point 2 is False. It's easily possible to write code compatible with both 2
and 3. It's becoming less pleasant as one can't take advantage of the great
new features from v3.6+, but I've done that for about a decade now.

I agree somewhat with Point 1, but the Python ecosystem is larger than Ruby's.
Each domain could have moved separately, and did, to some extent.

~~~
pansa2
Sorry, I meant that Python 3 code can’t use dependencies that are written in
Python 2. Therefore a library couldn’t upgrade to Python 3 until all its
dependencies had upgraded.

------
aeturnum
I don't really understand all the grumpiness around Python releases. There are
lots of programming languages that depend on interpreters or VMs (Java, Erlang
/ Elixir, Go [kinda]). Those languages have versions which are no longer
supported and, as far as I know, that's not controversial.

The old versions exist. They are not supported. You can choose to use them if
you wish or use the latest. I don't see many complaints about the fact that
Java SE 6 (or whatever) isn't getting updates anymore.

I think the Python team fucked up the 2->3 transition, but that was 12 years
ago! Do other people have explanations as to why old versions of the Python
interpreter are associated with so much emotional investment?

~~~
jeffrallen
Go 1.15 can compile Go 1.0 programs. That's why I'm grumpy with the Python
team but not grumpy with the Go team. There's simply no more to be said about
the situation than that.

~~~
mixmastamyk
Go does a lot less language wise, and is a lot newer. Didn’t have to change
1991 design choices. Unicode was a big shift.

~~~
t-writescode
It's also "Go one point ten" and "Go one point fifteen". That's a minor
version update. Backwards compatibility is common between minor version
updates - in fact, it's part of a major version update that backwards
compatibility breaks.

~~~
jeffrallen
It is minor because the Go team understands their responsibility not to make
major changes. Which they learned in part from watching Python screw it up.

~~~
t-writescode
Python didn't screw up. They ticked the "major" version number. That's what
the 3 in the number is:

major.minor.revision: [https://semver.org/](https://semver.org/)

They ticked the version at the right spot, which means it's (edit: not)
backwards compatible.

~~~
jeffrallen
They screwed up because it turned out enough of their users didn't want a new
major version that it split their community for years.

------
CapriciousCptl
Python2 aside, judging by the rest of these posts, maybe it's just me but I
haven't seen any problems with forwards compatibility in Python 3. That is,
stuff written 5 years ago runs fine on 3.8. The only issues I've had is with
virtual environments and pip freeze because some older Python versions relied
on packages for features now in the Python standard library, but since we know
how to spot those now that's not too bad of a fix.

On the other hand, Python gives a growing and continuously maintained standard
library and none of the headaches that, say the JS ecosystem gives.

That said, not all of the features are great all the time. Async/await comes
to mind, which adds a lot of complexity without the performance gains even
senior programmers might expect. But overall, we're already using features in
Python3.8 for projects, and have upgraded our instances to Python3.8 without
issue. I guess it's possible we leave some pip dependencies in the dust
because they may have some incompatible code with a future 3.x release, but we
haven't had a problem before. Tests permitting, we'll do the same for 3.9 if
we find something we like or might wait a few years.

~~~
robocat
> and none of the headaches that, say the JS ecosystem gives.

ECMAScript is the language, and it is amazingly backwards compatible back 20
years to about the start of the century without any trouble, and plenty of
tooling like TypeScript can target ECMAScript 3 released a score of years ago.

Python could have added a ‘use strict’; in 3.0 to avoid a breaking change!?

Sure, since then browser features have radically changed and frameworks have
changed, but the language itself has been extremely solid. Conflating JS and
the ecosystem is not a fair comparison.

Also there have been many competing different implementations of JS engines,
with amazing levels of compatibility between them (even Internet Explorer 5.5
released 2000 only had a few very minor known quibbles in the ECMAScript
implementation).

Edit: Of course Unicode is actually hard to deal with because ECMAScript uses
UTF16 for strings and symbols, even though the source code is usually written
in UTF8. And note that the u flag was added to RegExp expressions to deal with
Unicode better in ES2015 (especially U+10000 and greater, which are generally
difficult to deal with in ECMAScript code).

~~~
CapriciousCptl
On a technical level, you're absolutely right, JS as a language has an amazing
amount of backwards compatibility. So much that IE running on Win XP can run
things that Babel compiles from ECMAScript X in 2020.

But, the ecosystem is really something different entirely, and this isn't
meant to be a slight to JS at all. It's just reality when running production
code in 2020. Python's standard library is comprehensive, well-maintained and
well-documented throughout. JS, by comparison, relies on packages from npm for
the same features. Which means the issue my org has with the JS ecosystem is
the stuff that's not built into the language spec or otherwise maintained by a
central body, not that the things built into the language isn't standing the
test of time or something like that.

I hope that explains things.

~~~
robocat
> But, the ecosystem is really something different entirely

Most of the ecosystem changes are driven by externalities - web-servers,
browsers, developers. You can still _choose_ to use an old web framework and
it will work on modern browsers.

That is entirely different from the Python 2.x -> 3.x change.

The days of a simple CRUD web page delivered by a server are long gone. jQuery
is still brilliant at adding adornment to HTML produced on a server. Putting
your view and controller into JavaScript just makes sense.

SPAs need completely different frameworks to support the highly complex needs
of client-side rendering and interaction. Ten years ago component based
renderers were not common and developer-friendly syntax hardly existed.
Frameworks are being pushed by the needs of huge systems (Facebook), server
side pre-rendering, and partial updates (correct term? to improve first load
and responsiveness).

Also the features available in a modern browser are radically different.
Remember building up a string of HTML in JS for performance reasons? Avoiding
the DOM because it was slow? So many features only started becoming reliable
or available around Internet Explorer 11, yet now IE11 is hardly ever
supported because it is missing _critical_ features. An example is that in
older Internet Explorer and Safari, you could theoretically update CSS
rulesets from the DOM, but in practice doing anything dynamic risked crashes
and memory leaks (even loading new CSS pages was difficult and error prone and
browser specific e.g. detecting CSS load failures).

Note: I was supporting the same JavaScript codebase for over a decade
(initially IE5.5). There were _no_ breaking changes in the ECMAScript, and
very very few in the DOM (mostly driven by dropping IE specific DOM). The
changes in the codebase were mostly driven by wanting to support new features
in browsers.

------
TekMol
On the current Debian (10), when I do this:

    
    
        $ apt install python
        $ python -V
    

I get this:

    
    
        Python 2.7.16
    

So EOL for some definition of EOL.

But probably not in terms of "Don't use it in production anymore". Because in
many places, what is in the current stable Debian repos is what is used.

~~~
l3s2d
On most Linux distros the `python` package corresponds to Python 2. Likewise,
most distros have a `python3` package with a relatively recent Python 3
version. This is for compatibility reasons and won't change anytime soon.

The most notable exception is probably Arch Linux, which has Python 3
available in the `python` package.

~~~
afiori
On fedora `python` runs Python 3.8

------
leephillips
The Fortran spec was published in 1957. Today’s Fortran has features that were
not dreamt of then, such as array operations with automatic parallel
execution. The changes are a bit more drastic than improving Unicode support.
But I can take a Fortran program written in 1960 to run on a computer that
needed its own building, that was fed into a machine without an operating
system using punched cards, and compile and run it on my phone.

~~~
beagle3
I don't remember the details, it's been nearly 30 years, but ... I had to fix
Fortran-II (1960 or so) programs so that the fortran-77 compiler (on the same
IBM VM/CMS 390 system) would agree to compile them. The changes weren't big,
but they were needed. (I didn't write the original - I was just the maintainer
at the time)

I also needed to change a lot of things porting the same program a few years
later to an IRIX based machine whose name I don't remember right now (Octane,
perhaps?). And that was a well behaved program that did not try to change the
value of 4.

Python 0.9.1 programs (Earliest I used) required much fewer changes to run on
2.7 -- partly because I never used stuff like field access control (which was
luckily dropped from the language). Python 3 requires a few more changes, but
I suspect I can still compile Python 0.9.1 on modern hardware and run the
original code.

~~~
true_religion
> Python 0.9.1 programs (Earliest I used)

This inspired me to download Python 0.9.1. to find out what field access
control was.

I did find it.
[https://www.python.org/download/releases/early/](https://www.python.org/download/releases/early/)

And amazingly it compiles, and does so in just 1.5 seconds on an iMac (unlike
my Typescript project which is compiling at 90 seconds and counting.... hmmm).

Unfortunately, even now with access to the source code I can't find anything
about field access control.

What was it? How did you use it?

~~~
beagle3
Ok, I've just downloaded the 0.9.1 sources, and it's not there yet, and in 1.4
it's not there anymore, must have been somewhere in between, maybe 0.9.4 or
so;

I'm not sure if they were ever properly implemented, but there was a point in
time in which the grammar had some provision for declaring methods private
and/or fields read-only or something like that. I do remember I disliked the
idea and never used it, and likely it wasn't popular because it's gone.

I can't find any version other than 0.9.1 to download, and trying to do
newgroup archeology through Google Groups is incredibly frustrating. I've
given up after about an hour of trying to find old mentions.

------
duckerude
I like this visualization of Python's release cycle: [https://python-release-
cycle.glitch.me/](https://python-release-cycle.glitch.me/)

~~~
kevindong
Python 3.0 is surprisingly short (~7 months) and Python 2.7 is impressively
long (~9.5 years).

~~~
Izkata
I have no experience of this myself, but I remember people saying that 3.0 had
at least one major-yet-unnecessary incompatibility with 2.7, and that
converting 2.7 to 3.2 or 3.3 was significantly easier than 2.7 to 3.0 (and so
that could explain the speed it was dropped - the fix may have been 3.1 and
not 3.2 like I have in my head)

~~~
pansa2
Perhaps they were talking about the explicit `u` prefix for Unicode strings?
This was present in 2.7 but missing from 3.x until 3.3 [0].

[0]
[https://www.python.org/dev/peps/pep-0414/](https://www.python.org/dev/peps/pep-0414/)

------
AndrewDucker
Yup, the sunset date for Python 2 was moved from 2015 to 2020. People have had
plenty of time to move.

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

~~~
pornel
It's not that nobody knew it's going to be EOL-ed, but I haven't met anyone
taking it seriously. I've only seen a circular logic of "Python 2 is just
fine, and nobody uses Python 3, so no rush". I've seen companies started and
intentionally built on Python 2 after the original EOL deadline.

It baffles my mind, because I've lived through PHP 4→5 switch. It was a major
breaking language change that affected every object assignment. It felt like
it was dragging on forever, but in retrospect, compared to Python, that was a
quick and successful upgrade.

~~~
abiogenesis
It is probably there are more disposable PHP projects than Python ones,
meaning that the PHP code base is more frequently replenished with new
projects that usually start with the latest version of PHP.

------
mrfusion
It’s nice you don’t have to choose between python 2 and 3 anymore.

~~~
devenblake
According to a quick `apt remove python` you still need Python 2 for (on
Debian Stable, at least):

* minetest

* mpv

* npm

* qbittorrent

* smbclient

* virtualbox-6.1

These are the more popular ones. I write and don't hate (compared to Python2)
Python3 but apparently if I remove Python2 I have to shed all these programs
because they still depend on it!

~~~
marcan_42
mpv, really? That has nothing to do with python as far as I know. There are
Python bindings to libmpv, which I maintain, but I doubt they're included in
Debian's mpv package (and they're Python 3 compatible).

Maybe it's a VapourSynth thing?

~~~
shakna
mpv seems to use python-docutils for generating the documentation, which has
had a very long path towards full Python3 compatibility and only really
"reached" it last year (after Debian's freeze).

~~~
formerly_proven
Yeah but the tools for building the docs wouldn't be included in a binary
package?

~~~
marcan_42
Exactly, build tools shouldn't be deps of binary packages.

------
remram
They are unsupported by the PSF, but still supported by Linux distributions.
For example Ubuntu 16.04 uses Python 3.5 and is still supported until April
2021 (security updates until April 2024).

~~~
pmontra
Yep. BTW an easy way to use more recent versions of Python (and multiple
different versions) is to use a version manager. I like asdf which is multi
language (and multi database)

[https://asdf-vm.com/](https://asdf-vm.com/)

The Python plugin is at

[https://github.com/danhper/asdf-python](https://github.com/danhper/asdf-
python)

~~~
mixmastamyk
pyenv is the python-only alternative.

~~~
pmontra
Yes. I like asdf because most projects are multilanguage nowadays, usually
something + Node. Asdf also manages databases so I don't have to keep track of
docker containers for multiple versions of postgresql or mysql.

------
satya71
I see a lot of comments about Python 3 was 12 years ago. Yes. But Python 3.0 -
3.4 were not usable.

Most important third-party libraries were only ported Python 3.5 onward. So
the real Python 3 start date should be 2015, not 2008.

~~~
mixmastamyk
The tools for upgrading code to Py3 paradigms started in 2.6 however. There
was plenty of time to do it. Unless a project dealt heavily with unicode the
transition was trivial if any effort was made.

~~~
satya71
Yes the translation tools existed, but they were not quite enough. Besides
real world doesn't move in one swoop. You need co-existence.

I very much wanted to move to Python 3, but critical libraries I was using
were not there. And running both 2 and 3 at the same time was very unergonomic
until python-future [1] became stable and widely-used.

[1] [http://python-future.org/](http://python-future.org/)

~~~
mixmastamyk
A decade is pretty good for free support. You are welcome to pay to continue
as well.

About five years ago I used six and it worked well enough. Now both obsolete.

------
ram_rar
I am soo glad, I pushed back on python migration in my team until 3.6 was
released. We were running large amount of django code base in 2.X and 3.6 was
the only version which had some reasonable improvements to upgrade to. I
sincerely hope the python community has learnt it lesson and wont break
backwards compatibility in 4.X releases.

~~~
BlueTemplar
Why would they call it 4.X then ?

~~~
abiogenesis
Why does Java call the latest version 15?

------
nojvek
I would have been okay if the only breaking change in python 2 -> 3 was
strings are Unicode by default.

But they went with the logic of “if we’re gonna break, why not break a bunch
of other things and take this opportunity for a different python”

Needless to say, the folks in charge of python didn’t think things though.
It’s a big fat breaking change with no real automated way to upgrade. A whole
bunch of apis are now different. At my company even after a year it’s still a
pain having some scripts only work in py2, while others in py3.

Python3 pulled a google.

------
throw8769758
As someone interested in learning Python, does it mean I dont have to worry
about version 2.x? Do I just skip any book or tutorial containing that
version?

~~~
amluto
Yes. Unless you specifically need to work on legacy code, start with Python 3.

IMO you should consider simultaneously learning mypy and Python type
annotations. Python with some typing is a vast improvement.

------
mlang23
I believe the fundamental error was to try and break backwards compatibility
in a dynamic language. I can see how this would be much safer for a strongly
typed language to pull off. It would still be a PITA, but at least I'd feel a
bit more save about it. I watched the transition of a NVDA from Python2 to
Python3. It took a pretty long time, and some of the commit logs read like
voodoo. I would really not want to be in charge of having to migrate a semi-
largish codebase from Python2 to Python3, especially if there is only limited
amount of automated tests.

~~~
leephillips
Python is strongly typed.

~~~
mlang23
Since when?

~~~
afiori
In some contexts strong typing means that all values have a well-defined
unique type that cannot be changed. For python this means that the language
takes care of performing meaningful conversions when a value of a type A need
to be turned into type B and also that there is no way to convince python that
a value is a String (for example) if that value is not a valid string.

Or from wikipedia:

    
    
       In Luca Cardelli's article Typeful Programming,
       a "strong type system" is described as one in 
       which there is no possibility of an 
       unchecked runtime type error.

------
ed25519FUUU
For those that think migrating from python2 to 3 is easy: no. You’ve clearly
never tried to migrate different companies/environments.

Sure, the code now _runs_ in the py3 interpreter, but guess what!? That was
the easy part! Now go hunting down Byzantine build scripts and environments to
find out how it was deployed and tested. Tested lol? Ugh and guess what? The
code base has commits that we’re never deployed to prod. What do you do now?
You basically own a service that hasn’t been deployed in 4 years and a branch
that was never deployed ever.

~~~
lolc
The things you describe are real problems but they are orthogonal to the
Python migration. You have to pay that cost eventually, with or without
migrating. It's not just Python that moves.

------
mixmastamyk
String interpolation everywhere for the win! Commonly, unfortunately called
“f-strings”. :D

Ordered more efficient dicts was another win.

------
chishaku
Does anyone know about Python 4? Is there anything particularly notable or
exciting on the horizon?

~~~
pansa2
“The plan is not to do 4.0 until 2.7 is barely a faint memory, and then we
will consider how to handle the transition very carefully.” - Guido van Rossum

[https://mobile.twitter.com/gvanrossum/status/128544327896012...](https://mobile.twitter.com/gvanrossum/status/1285443278960123904)

~~~
true_religion
That was Guido... but Python has moved to design by committee now so anything
goes.

------
fouronnes3
Serious question: when will Python be done?

~~~
gruez
Is there any programming language that's "done"? I feel like any programming
language that's "done" is closer to "abandoned" than the developers saying
"the language is perfect now, there's no need to add or change anything".

~~~
eesmith
TeX is the closest I know of.

~~~
monadic2
I was about to agree with you before I realized I use XeTeX, not TeX.

