[Alex3917]

Python3 has really been the norm since 3.4, which was released in 2014. After that it took another year until most major packages were updated to Python3, but that happened at some point in 2015. By 2016 there weren't many packages left that weren't Python3 compatible, or that didn't at least have Python3 replacements.

[jonnytran]

This is simply not true. From 2014 to 2017, I worked at a place where I kept starting new projects in Python 3. But people with less foresight wouldn't let their Python 2 habits die. It was a constant struggle to get anyone to realize that Python 3 was the future, and the majority of the code ended up using Python 2. In 2019 when the end-of-life for Python 2 was finally announced, I knew of companies scrambling to upgrade.

I can't help but contrast this with the upgrade from Ruby 1.8 to 1.9. It was also painful, but no one in the community was holding on to 1.8 years later.

[pansa2]

> I can't help but contrast this with the upgrade from Ruby 1.8 to 1.9.

One difference is that upgrading Ruby from 1.8 to 1.9 brought a significant performance increase, whereas going from Python 2.x to early 3.x, performance actually got worse.

AFAICT this was mostly caused by the removal of the machine-word-sized integer type - in Python 3, even 1+1 is calculated using arbitrary-precision integers.

Python 2 => 3 had lots of other problems as well - ultimately they changed just enough to break everyone’s code, but not enough to make upgrading worthwhile.

[tonyedgecombe]

I've often wondered if part of the problem was supporting Python 2 for so long and hence prolonging the pain.

[rightbyte]

Without that I think many would lose trust in Python and just switch language.

I mean it has only been 11 years since Python 3.1/2.7 and that's probably a common lifespan for maintenance mode code projects? 3.5 is still supported and that one is 5 years old. Why the hurry.

[tonyedgecombe]

Why the hurry.

Because some people will always leave it to the last moment or beyond. Meanwhile the Python team has had the overhead of supporting more code than necessary.

[xiaodai]

What r they gonna switch to?

[newen]

Python is not technically superior to other languages enough that you can rhetorically ask that question. It’s main advantage is the ecosystem and network effects. If a bunch of people, especially the people who work on numpy, scipy, etc., decide to work on developing libraries for other languages like R and Julia, the data science ecosystem would switch over in a few years. Similarly for other fields people might switch to languages like Elixir, Haskell, OCaml, Go, Swift, Scala, Ruby, Kotlin, etc.

[philwelch]

> Python3 has really been the norm since 3.4, which was released in 2014. After that it took another year until most major packages were updated to Python3, but that happened at some point in 2015.

So from the perspective of an application developer who uses package dependencies, using Python 2 was the norm until 2015 at the earliest? That sounds about right to me.

[cortesoft]

Someone forgot to tell my company...

[core-questions]

That someone is now you, innit?

[chaostheory]

I beg to differ as someone who's been forced to use python 2 at work until next year. As for the python ecosystem as whole, it feels at the earliest the transition to 3 had to be around 2017 - 2018 before most popular libraries got with the program. Then again the numbers could prove me completely wrong. I just remember personal pain points well. By comparison, the Ruby ecosystem was much faster in transitioning.

[framecowbird]

most Linux distros still have Python 2 as the default though, right?

[lbhdc]

Fedora only includes py3 by default in workstation 32.

[marcuskaz]

No, Ubuntu 18.04 shipped with Python3 as the default.

[3np]

Not true. Vanilla 18.04 LTS ships with no Python installed by default and the main repos `python` package is 2.7. Same for Debian 10. Ubuntu 20.04 switched the `python` package to Python3.

Even conservative CentOS (where Python is a base dependency for the system, as opposed to the above) is on Python3 as of now though.

As far as I am aware, Debian 10 buster is the last mainstream LTS distro to default to python2. Should change next year with Debian 11.

[3np]

AFAIK the remaining notable one is Debian. Ubuntu LTS moved to 3 with 20.04.

[dharmab]

Only server/LTS versions which need Python 2 for backwards compatibility.

[loeg]

Not most, no.

[abiogenesis]

CentOS 8 and the latest Fedora doesn't even come with Python 2 installed.

[ATsch]

That's just a measure for backwards compatibility, so python2-only scripts don't cause cryptic errors when they have a `python` shebang. Many distros ship without python2, but will probably still link `python -> python2` for the near future.

[awill]

Anyone who works in an enterprise with old code has been working on migrating Py2 for ages.

[n0rbwah]

In 50 years, I bet they'll still be looking for python 2 developers to work on old python code...

Or not... it's not like you can't throw a python 3 dev at an old python 2 codebase and tell them to work on it. Even if that probably wouldn't make them very happy about it, they wouldn't be lost.

But I'd bet an arm that there will still be python 2 codebases running in production in the next decades with companies very unwilling to do the work of migrating it.

[stjohnswarts]

Is it really that hard to work on python2 code if you've only done python3, provide you have proper documentation and the web to look up quirks?

[n0rbwah]

No, they made a big deal of giving a ten-years period to developers to port their code before depreciating python 2.

But honestly, there are more breaking changes between two versions of ruby than between python 2 and 3. And during the time python 2 was still supported (until the last day of 2019), most features that made it into python 3 and could be backported were backported into python 2.

It will be a pain for those who aren't used to python 2 encoding errors and other nice stuff that they got rid of in 3 to make it a nicer and more robust language. And the will miss the new and shiny features that will make it in new python 3 version after python 2 EOL.

But apart from that, it's almost the same language, they just made the transition from 2 to 3 to be able to introduce some breaking changes in places that unfortunate design choices had made their way into the language and couldn't be rolled back because people running python 2 in production depended on those. So they upped the major version, introduced some breaking changes (but not that much really) and gave developers 10 years of support for the older language so they could port their codebase to the new version.

And porting a python 2 app to a python 3 app isn't such a hard task. But! If you've got a big app that's working now, even if the changes aren't that drastic, you can't be sure that the port won't introduce some hard to find bugs that will be a pain to debug. Hence why plenty of companies are still running python 2 versions of their apps and will do so for the forseeable future.

But, throwing a python 3 dev at a python 2 codebase is totally doable, it's just that the guy or gal will miss the shiny stuff that didn't get backported into 2 and will break their teeth on some behavioral changes between the two languages.