Live data from Hacker News

Python 2 will be replaced with Python 3 in the next RHEL major release

access.redhat.com

261–270 of 341 posts

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#261

As someone completely ignorant in everything python... can someone explain why Python 3 has never replaced Python 2?

I started using Python in early 2016, since then I have looked at hundreds of packages on github and pypi and I can't remember one of them being strictly Python2.

The "2 to 3 dilemma" doesn't exist in my life, even though I use Python on a daily basis. I guess it's because I'm late to the game and I'm not working in a big corp with lot's of legacy code. Or maybe it's the field? I use Python for web stuff and tooling.

Anyway.. in my life Python2 is history. The only time I hear from it is either threads like this one or code examples on old blog posts.

> can someone explain why Python 3 has never replaced Python 2?

I think this is inaccurate. Python3 may not have replaced Python2 for everyone, but it looks like it has replaced Python2 for most projects on github.

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#262
post #3

This is good: - Python 2 support officially ends somewhere in 2020 - most popular packages are now compatible with Python 3 - Python 3.7 performs about as well as 2.7 with future release expected to be better Although it still took way too long, if you consider Python 3.0 was released about 10 years ago.

> "- Python 3.7 performs about as well as 2.7 with future release expected to be better"

are you sure on that? my laptop (2.7 ghz 4 cores, 16gb ram) would fall behind my desktop (3.8 ghz 6 cores, 64 gb ram) because it would be paging things in and out of ram, but once the models started running (like XGBOOST), py2x was about twice as fast.

I am not stating this with difinity, because I was not trying to benchmark the two. Just that I casually noted my laptop would always finnish running the same code in 1 hour vs over 2 hours on my desktop.

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#263
post #95
post #3

This is good: - Python 2 support officially ends somewhere in 2020 - most popular packages are now compatible with Python 3 - Python 3.7 performs about as well as 2.7 with future release expected to be better Although it still took way too long, if you consider Python 3.0 was released about 10 years ago.

> most popular packages are now compatible with Python 3 I often see this but I think it's a perception from the Internet/web world. I work for CGI, all (I'm not kidding) our softwares (we have many) are 2.7. You will never see them used "on the web/Internet/forum/network" place but the day-to-day job of millions of peoples in the industry is 2.7. And we are a tiny focused industry. So I'm sure there is many other in…

by "the CGI industry" you most likely mean Disney. Disney can afford the investment to make the upgrade.

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#264

Earlier quoted context omitted.

The double standard is that people still stick to Python despite those problems. If we're being honest and all conspiracy aside, imagine the same story for Ruby (a very similar language in terms of capability, features and performance), everyone would be laughing at them and the language would be pulling a Perl right now.

Those three scripting languages actually an interesting comparison. Perl 5 -> 6 broke all your code in exchange for a whole new language. Some people moved to Perl 6, some to other languages, and a lot stayed with Perl (5), which still runs programs written in Perl 1. Ruby 1.8 -> 1.9 broke most of your code in exchange for minor cleanups. But Ruby was Rails, so the culture accepted constant rewriting and breakage, an…

> The result has been a decade-long war in which Python fans try to shame Python users into moving to version 3.

I think that's the most succinct way to put this whole debacle I've ever seen. I'm totally stealing this.

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#265
post #95

Earlier quoted context omitted.

> most popular packages are now compatible with Python 3 I often see this but I think it's a perception from the Internet/web world. I work for CGI, all (I'm not kidding) our softwares (we have many) are 2.7. You will never see them used "on the web/Internet/forum/network" place but the day-to-day job of millions of peoples in the industry is 2.7. And we are a tiny focused industry. So I'm sure there is many other in…

Well, the CGI industry had money, competent people, and 10 years to upgrade. An entire decade. And a LOT of tooling and documentation to help. I made a lot of code conversion from 2 to 3. Most of them took me a couple hours to a few days. I'm currently working on a 2.7 project that will never migrate because they literally patched the cpython runtime, but you can't freeze a whole community because some will take bad…

> Ruby and node did it in a few months and told the community to move or die.

Uh, Ruby’s big compatibility breaking upgrade (1.8 -> 1.9) took more than a few months, it took years for the community to fully move. (Because of Ruby’s pre-2.0 versioning practice, 1.8.x -> 1.9.x was a major version upgrade, and it was actually a more significant one than the 1.9 -> 2.0 update. But lots of people stayed on 1.8 throughout most of the 1.9 period and the transition didn't really complete until late in that period or early in the 2.x period, and 1.8.7 was getting maintenance releases for four years after 1.9.1 stable release.)

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#266

It's for system use. You should never depend on the vendor-supplied compilers for anything, because their goals are different from your (the developer/application-wrangler's) goals. Always develop in a defined, controlled virtual environment, period. If you want be stylish, there's a fancy new thing called a container in which you execute your application in defined, controlled environment. :-)

This is really by far the most important point in the thread. I understand the points about embedded use cases and all the other stuff that people bring up when the flames come out in 2 vs. 3. But this is specifically about RHEL.

If you're using RHEL, the point here is almost entirely moot. You should never have been depending on system python for anything important anyway. If RHEL replacing Python 2 with Python 3 breaks any part of your code or your company, you have already made a huge shit sandwich for yourself.

The fix, however, isn't that bad. Just start using virtual environments. It will take you a while to unravel hidden dependencies, but it's doable in a reasonable amount of time.

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#267

Earlier quoted context omitted.

Got a source for the performance regressions? Some things are faster in Python 3 than 2 "Most popular" packages, which ones? Most moved a long time ago to Python 3

Here's some light benchmarking (this was posted a few weeks ago I think...) https://hackernoon.com/which-is-the-fastest-version-of-pytho... Basically once 3.7 is out (which is soon), CPython3 will finally be broadly faster than CPython2.7. Interpreter startup time is still annoying though. I really wonder what the right strategy for addressing that is. Like honestly 2.7 is faster than 3.x, but 2.7 CLI tools still fee…

Perfect example of how not to use plots. Y-axis simply says mean, mean of what? I can't tell if lower is better or worse.

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#268
post #3

This is good: - Python 2 support officially ends somewhere in 2020 - most popular packages are now compatible with Python 3 - Python 3.7 performs about as well as 2.7 with future release expected to be better Although it still took way too long, if you consider Python 3.0 was released about 10 years ago.

> - most popular packages are now compatible with Python 3

And if one isn't, then it's another incentive to update it or abandon it.

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#269
post #95

Earlier quoted context omitted.

> most popular packages are now compatible with Python 3 I often see this but I think it's a perception from the Internet/web world. I work for CGI, all (I'm not kidding) our softwares (we have many) are 2.7. You will never see them used "on the web/Internet/forum/network" place but the day-to-day job of millions of peoples in the industry is 2.7. And we are a tiny focused industry. So I'm sure there is many other in…

Well, the CGI industry had money, competent people, and 10 years to upgrade. An entire decade. And a LOT of tooling and documentation to help. I made a lot of code conversion from 2 to 3. Most of them took me a couple hours to a few days. I'm currently working on a 2.7 project that will never migrate because they literally patched the cpython runtime, but you can't freeze a whole community because some will take bad…

> Most of them took me a couple hours to a few days.

Since 2008, the automated tooling has vastly improved. I'd bet most of those "few days" issues would either not exist or take hours given today's advances in the automated code translation and new knowledge on stack-exchange.

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#270

Earlier quoted context omitted.

The double standard is that people still stick to Python despite those problems. If we're being honest and all conspiracy aside, imagine the same story for Ruby (a very similar language in terms of capability, features and performance), everyone would be laughing at them and the language would be pulling a Perl right now.

Those three scripting languages actually an interesting comparison. Perl 5 -> 6 broke all your code in exchange for a whole new language. Some people moved to Perl 6, some to other languages, and a lot stayed with Perl (5), which still runs programs written in Perl 1. Ruby 1.8 -> 1.9 broke most of your code in exchange for minor cleanups. But Ruby was Rails, so the culture accepted constant rewriting and breakage, an…

> But Ruby was Rails, so the culture accepted constant rewriting and breakage, and people went along.

The main reason people switched probably wasn't rails making people expect breakage, the main reason was that (a) it was relatively easy to rewrite your code to work on both 1.8 and 1.9 (as long as your dependencies had already done it), and (b) 1.9 was much faster.

Post reply on HN