Live data from Hacker News

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

access.redhat.com

321–330 of 341 posts

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

#321

Earlier quoted context omitted.

I’m not sure what you’re complaining about here. Those applications will still work.

The attitude of most python3 devs, which can be surmised as: "I moved my Twitter clone from python2 to python3, and it was easy. What's the big problem? You've had ten years to get this done! Hurry up, you're hurting my productivity."

Well if you’re not happy about the EoL part then that’s a fair response.

If you don’t care (because your apps will still work and they don’t need or can’t be updated) then it shouldn’t really come up...?

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

#322
post #128

Earlier quoted context omitted.

>> It's just that we, as a community, will stop to pay the price for the ones that didn't move. If you want to stay there, you'll pay a commercial actor for it. That's very well put. But I guess this can happen only with big, important, projects where you can afford to loose/upset some users...

No that's just how IT works. Your games don't work in windows XP anymore. Actually, your USB3 mouse doesn't work on windows 7 out of the box. Centos have LTS, but still EOL. Ubuntu init system was changed to upstart. Then to systemd. Also gnome, then unity, then with new menu/notif/systray semantics, then back to gnome (but shell), and soon wayland. It breaks a lot of things. Firefox new addons don't work with some a…

"And if any of that is not enough, well, Anaconda Continuum will be happy to do business with you."

Yes, this is a key point that seems to be forgotten. The Python development team will end their support on 1st January 2020, but there are other providers with Python expertise who will almost certainly pick up the commercial opportunity, e.g. ActiveState, and possibly even Red Hat with a separate product.

This is not the end of Python 2, it's going to be a transition to a different support model. Commercial users either pay to move up, pay to rewrite the Python code with something else, or pay for a super long-life version of Python 2.

The awkward part may be academic research, where there's a probably a lot of Python 2 code that has no maintenance budget. I would not be surprised if a project appears to build no-support versions of Python 2 with essential fixes after 2020.

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

#323

Earlier quoted context omitted.

I’m not sure what you’re complaining about here. Those applications will still work.

The attitude of most python3 devs, which can be surmised as: "I moved my Twitter clone from python2 to python3, and it was easy. What's the big problem? You've had ten years to get this done! Hurry up, you're hurting my productivity."

Just curious, what parts of your code are not portable to Python 3? The biggest barrier usually seems to involve strings/Unicode. Or are you relying on packages that don’t have Python 3 support?

In any case, it sounds like you have a stable Python 2.7 system running, so what’s the issue? Nobody’s going to come and take your code away from you.

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

#324

Earlier quoted context omitted.

Automated tests is extremely beneficial for such cases. You should know that the code works before you deploy.

Easier said than done. This isn't the web world, things aren't so simple. How do I mock a temperamental motor controller responding to AT commands? I mean, I'm sure it's hard enough to replicate the oddities of their serial port parser, but the temperamental part is gonna be tricky. This is an embedded system I'm talking to, which is parsing bytes coming over a serial port in an interrupt service routine at 16 MHz wi…

Fortunately, on the web, things never go wrong. Hardware never fails. Traffic never spikes. You never face DDOS attacks or people actively trying to break your security. The network is never unpredictable. It isn’t a complex distributed system consisting of hundreds of interconnected parts. Every potential failure can be anticipated and easily tested against. And every component scales effortlessly as the system scales by orders of magnitude. A lowly web developers could never understand the Herculean feat of writing a Python script to communicate with a motor controller over a serial port.

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

#325

Earlier quoted context omitted.

What do you mean by double standard? Everyone in the community, including the core developers, acknowledge that the 2 to 3 story was full of mistakes. They have promised not to make it again. And they took some actions to remedy the problems, and that's why Python 3 is finally succeeding. I recommend this presentation by Victor Stinner at FOSDEM 2018 which talks about it: https://fosdem.org/2018/schedule/event/python…

Could someone provide a summary of the kinds of mistakes/remedies?

One mistake was providing 2to3 as a migration path. This required projects to move completely from 2 to 3, for libraries it meant that they had to either stop supporting 2 (which were the majority of their users) or forking and maintaining both versions. The remedy was to make it possible for libraries to be both 2.7 and 3.x compatible, using tools such as six.py and making some changes to 3.x to make it more compatible with 2 (e.g. adding u'' strings).

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

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

Once again, I don't say Python should not move on, actually, as a CGI "dev" (Technical Director we say) myself, I would LOVE to trash 2.7 and move on.

I was just rambling about "most popular packages" which are only web/network/academic oriented while a huge part of the Python user base don't use them at all. It's just something the "Python community" can't see because most of them are web/network/internet/academic dev (and maybe it explain why they thought it could go well with breaking compat', internet bubble?).

I really want Python to move. I had the opportunity to discuss with some vendors involved in the industry they told me Python 3 switch was a running gag... I hope 2.7 will be such full of security hole my industry will finally do this once for all and stop joking (they will never move on instead), but please stop tell "most popular packages" represent how Python is used as if it was what should been seen, it's definitely not.

TBH, I think Python community give great tools for transition and write close compatible Python 2 and 3 code is not that hard.

Once my industry will be 3+, as a dev, I will love to follow the deprecation period.

EDIT: I love your blog SamAndMax. :D

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

#327

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

For us the primary reason is because not only is Python 2 the default in RHEL 6 and RHEL 7 (and thus downstreams like CentOS and Scientific Linux), they don't even ship with Python 3 or have it in the base yum repos, so getting it installed on our thousands of diverse systems is nontrivial. Furthermore we have a large base of scripts, owned by many people, that use Python as they would use bash, so changing the defau…

There's SCL. It's a pain in the ass, especially if you want to ship RPMs, but it works and is - more or less - official.

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

#328
post #291

Earlier quoted context omitted.

>While nothing is really exciting in the 3.x branch. Sorry, have you looked at Python 3 lately? I don't think I can sum up all of the amazing work that's been done in one post (async? Cleaned up stdlib? Better errors? Not having an aneurysm from text encoding issues unraveling your whole project? New splat syntax?). I would really encourage you to check out what's happened in the last ten years. I think you'll find m…

I think that he's kind of right about the problem. In my opinion, Python's primary business value has been that sweet spot it occupies. It's not the most fun, but it's pleasant. It's not the fastest, but it's not too slow. It's not great on resources, but it's not too bad either. Good people will work with it, and they tend to be the "let's not get creative, let's just get it done" folks that businesses love. Mediocr…

> But if I was running a Python team that had been effectively just trying to get the job done in 2.7 for over a decade I would have to admit that I wanted to switch for my own sake - I think it would be unlikely to make them that much more happy or productive.

Part of being a software engineer is keeping your environment up to date. Sure, I could keep using Node 0.10. But I'll get no updates for security or fixes for bugs.

If you're on a team that hasn't updated to a version that's supported, then you're neglecting one of the fundamental ongoing maintenance tasks involved in software engineering. If that's "too hard" to do over the course of a decade, then perhaps there's something wrong with your engineering culture.

Sure, you don't have to do it. But don't expect the rest of the world to continue to support your old setup. If you have to compile Py2.7 from source because RHEL doesn't come with it, that's fair penance for not keeping up with the community. It's just about the most entitled thing in the world to say "I didn't spend the two weeks in ten years time to upgrade to a newer version [using the numerous automated tools] and I'm mad that the world at large isn't making it easy for me to continue to not do anything."

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

#329

Earlier quoted context omitted.

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…

That's right, but... It seems to me that all counter-arguments I get ignore the context that I set which is to not do things "simply because you have the money". What I get is "hey, you have the money and it's obviously the right thing to do so do it". "Having the money" is orthogonal to "it's the right thing to do" but this thread is too old to recover.

There is cost the individual user of an open source project has to consider, and there is cost the community of that project as a whole has to consider.

So from your perspective, just keeping the old version might be "the right thing to do", and at the same time the decision of the community to not support it anymore is also "the right thing to do" from their perspective.

As the community does their work unpaid, it seems you have no right to impose your perspective on them, except if you pay money for the necessary work. Which you are free to do.

I guess what the parent posters point out is that this will usually shift your own cost/benefit ratio in a way that upgrading becomes "the right thing to do" for you, too.

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

#330
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.

Why would previous versions of Python3 (e.g., 3.5, 3.6) not perform as well as 2.7? What about Python3 makes it slower? Is it a language design issue?

We’re in the process of migrating several keras/TensorFlow-based projects to 3.6, and I’m struggling to get my emacs environment setup to handle Python 2 and 3 code simultaneously.

Post reply on HN