Live data from Hacker News

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

access.redhat.com

171–180 of 341 posts

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

#171
post #64

Earlier quoted context omitted.

Quite the opposite. Python had deep problems that could simply not be fixed without BC breaks. The decision was made, and in hindsight it was the correct decision by Guido and other core devs. Look at PHP, and look what a total cluster of madness the language has become.

I think Python 3 was not brave enough, to be honest, to future proof Python: * an optional type system without hacks was not introduced (types in comments, really?) * the GIL was not removed or at least a solid parallelism story was not included, one that would allow Python to use all cores on a system while sharing, if needed, memory * no true performance improving changes were made; by this I mean stuff that improv…

"I say this because I'm a bit worried that long term Python has locked itself into a corner where it will keep getting pushed into as the other languages develop a better developer UX."

You can stop worrying. That is absolutely what will happen.

But it is a good thing. Languages should be something, not merely an accumulation of every fad and trend that appeared over its lifetime. That means eventually they will mature, and eventually hit a peak, and then fade. But during that process, at least you'll have a nice, mature language, instead of one always chasing the latest pretty-shiny, immature, confusing, crammed with too many features, with libraries constantly jerking around trying to keep up and always just a bit broken. Indeed, I kind of thing Python has already done a bit too much of the latter, and were I in charge of Python I'd give some serious attention to the idea of simply freezing the core language.

Python is what it is. Let it be what it is, because what it is is pretty good. It's by far my favorite language of the genre it is in. It's got way too much baggage to compete in the next arena, so let it be the master of the one it is in instead.

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

#172
The Internet may switch to 3 but industry will stay on 2.7 for the next decade and no EoL will change that. There is absolutely nothing that can change that because there is zero benefit to rewriting a decade's worth of code and no manager will authorise that.

So don't bin those 2.7 books just yet if you want a job at a big co.

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

#173
post #107
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.

You forgot one: - 90% of business code is written in Python 2.x

At least in our shop it's the other way around.

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

#174
post #158
post #107

Earlier quoted context omitted.

You forgot one: - 90% of business code is written in Python 2.x

We've switched from 2.7 to 3.4 (and upwards to 3.5, 3.6) in about a month or so. It delayed some deployments but nothing serious. If you do it step-by-step it's not that hard. The worst part was str/binary conversions but afterwards everything was a lot easier and better to maintain. If your company is big enough you should maintain and keep it up-to-date, not "it just works"(TM) and hope for the best after 10 years.…

It's not that hard unless you had some very advanced code utilizing Python 2 internals that were significantly changed in Python 3. However, conversion takes a lot of time and if something works, why should you be forced to change it?

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

#175

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…

So it took only a decade to bring Python 3 to levels of Python 2? Victory!

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

#176

Earlier quoted context omitted.

I don't know if HN can find any counter-examples, of a language that thrived through an incompatible, code-breaking upgrade. Of course. Swift 3 is one example. Ruby 1.9, as others have pointed out, is another. PHP is yet another, and perhaps more relevant because it is close to contemperaneous. It had its "Python 3 moment" with the migration to PHP 5. Lots of BC breakages.[0] That transition took about 3-4 years for…

Swift 3 is compiled. So you can provide the binaries and be ok. Ruby 1.9 is a great example of why you should not be too nice: they told everybody "you have a fews months, deal with it". The community moved. Python said "poor things, we understand, take those tools and years to do the thing", and the community cried, and did nothing. PHP literally failed. They canceled V6 and jumped to V7. The funniest part ? None of…

The remark about PHP was the move from version four to five. It was a big move.

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

#177

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.

Ruby took off because of Rails. Rails' convention over configuration defies Ruby's flexible nature. It feels more like Python. People prefer dumb unambiguous code over clever code. That's why Python and Rails succeeded

“Dumb, unambiguous code” does not rely on magic conventions that change with the whim of the framework developer.

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

#178
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…

OK, but then can the python community stop saying "Pretty much all of the packages are converted anyways!" if the answer is really "we don't care anymore if your aren't" ?

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

#179

Earlier quoted context omitted.

Companies who cannot upgrade their codebases are companies who cannot maintain their codebases. Eventually, the technical debt hurts your ability to deliver with both speed and safety. When your org can't do that, your org stops being competitive in the market, and if the market doesn't kill your company then the brain drain will. (small and non-notable exceptions for the literal handful of types of orgs where this i…

True, but is there a situation where upgrading will hurt instead of benefit? Not every solution is just as good for everyone. Think of the delayed upgrade game that some people play. They wait for others to upgrade first to get rid of new bugs at their expense. Now take this game at a 10 year extreme. For them, the new branch (e.g. new language etc.) is simply too risky. It's not that they are not smart to upgrade, t…

Yes, upgrading is an engineering expenditure like any other. If you devote manpower to maintaining your codebase you're not devoting it to user-facing features. As such, upgrading your codebase can hurt your ability to deliver some priority feature on-time.

But that kind of zero-sum thinking is myopic. My whole point is that if you only ever prioritize feature work, eventually you lose the ability to deliver features. Nobody in their right mind thinks you can have a company with zero technical debt, there's always a balancing act in play, but if your managers are just playing the risk card without, you know, doing an actual risk analysis which includes the risk of not being able to deliver future features, then your company isn't making smart decisions.

Now, there do exist codebases where you can make the logical conclusion that there really will not be any future feature work, but it's still running in production and so it will need support, and it's a fairly large codebase, and so there would be an enormous cost to re-certifying for the upgrade with very little apparent benefit. That happens, but it only (really, truly, only) happens in large enterprises with many, large codebases and only so many engineers. Those enterprises do have the resources to hire new employees and/or outside contractors to pay down the technical debt on these half-alive projects - they just aren't prioritizing those resources on the technical debt, even long after it became clear that the clock couldn't be stretched out any longer. Through painful personal experiences, I have zero sympathy for companies in that position who think that they can solve their problems with more firewalls.

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

#180
post #117
post #38

Earlier quoted context omitted.

It already does ~ ls -las /usr/bin/python 0 lrwxrwxrwx 1 root root 7 Jan 5 02:36 /usr/bin/python -> python3

What distribution are you on? My latest (!) stable Fedora still points at py2: ~ $ ls -als /usr/bin/python 0 lrwxrwxrwx. 1 root root 7 Mar 14 14:36 /usr/bin/python -> python2*

Arch linux. Sometime I even forget python2 still exists, P3 was moved as default so long ago...
Post reply on HN