Live data from Hacker News

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

access.redhat.com

251–260 of 341 posts

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

#251
post #174
post #158

Earlier quoted context omitted.

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?

Not referring to parent specifically. By "you", I'm referring to all python 2 hardliners out there.

Nobody's telling you to change your codebase. You're free to carry on using python 2.x. If it already works, it will continue to work in its current environment.

So why are you attempting to tell others in the python ecosystem, be it core maintainers, package authors or OS vendors, support your continued use of python 2 for free?

You want support beyond 2020, pay for it.

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

#252

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 had 1.9. It was like the Python 3 situation in miniature, and Matz has said he’s keen to avoid such a mistake again.

It also was in a minor version change 1.8 -> 1.9, but people moved on because 1.8 was declared EOL this is what Python was missing. Python 3 is 10 years old and 2.7 is still supported (bufixes, but still).

If you look at timing, Python 3 picked up for new projects in 2015, when PSF declared that no new features will be backported to Python 2 from 3.

I believe the industry will wait for 2020 to start migrating existing code after Python 2.7 will be declared EOL.

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

#253

Earlier quoted context omitted.

... Said the COBOL developers. To some degree, you may be correct, that there will be companies that refuse to upgrade for many years. By and large, I think most people will start to switch: * Small orgs will begin to see costs of maintaining legacy code skyrocket as it becomes harder and harder to get 2.7 interpreter support for newer kernels. Those that aren't already transitioning now will eventually bite the bull…

...and then there's Mega Large orgs, like Google, who are used to maintaining their own software. I am super curious what Google will do. The thing to watch is whether Chrome/Chromium (and therefore Node.js) can ever be built without using Python 2.7.

Mega large orgs have already moved, in some cases. They have the advantage of being able to throw significant resources into infrastructure to make switching easy.

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

#254

Earlier quoted context omitted.

The double standard when it comes to Python is mindblowing. No other language could have gotten away with such ridiculous fragmentation and perf regression for such a long period of time.

Double standards by whom?? Every other article or comment I’ve read since basically py3+1y has been incredibly negative about it. The only positive news about Python, recently, seems from people who were not around since the py2 days. Data science is where it’s at now, but it used to be massive and ubiquitous. Golang came at a time where public perception of Python was down the drain, and ate a big chunk of its lunch…

My interpretation of the usage share is that Golang ate a bunch of lunch that would've otherwise gone to Python. That is, people moving from other languages (Perl, PhP) to something else for various reasons.

Absent Go, I suspect many current Gophers would've landed on Python. So in a sense, Python lost people to Go. But I've never seen anything to indicate that there was a large migration from Python to Go, and certainly not because of 2 to 3 or public perception--whatever that means in the context of a programming language.

Python 2 is still the mainstay for Data Scientists. I've seen more resistance to moving to 3 there than almost anywhere. Which is pretty funny because it's the easiest code to port assuming your data science libs support 3 (and all the big ones do.)

I think it's more accurate to say that Go ended up with some of Python's potential mindshare, not that it stole a significant amount of existing mindshare.

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

#255
post #248

Earlier quoted context omitted.

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

Did not watch the presentation but IMO the primary mistake was not declaring EOL for 2.x sooner. Other languages had similarly breaking changes and they simply gave short time before legacy version was declared EOL and developers ported their applications to the new version. In Python it took 10 years, and even now you can't get companies to migrate, because why make developers do the work when application still can…

For the record, Python 2.7 EOL was originally 2015. In 2014, it was moved later, likely because RedHat would continue to maintain it for free anyway.

https://legacy.python.org/dev/peps/pep-0373/#id2

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

#256
post #246

Earlier quoted context omitted.

You don't have to rewrite it, just like you don't have to rewrite your COBOL or MUMPS or RPG or any of the other all-caps languages. In another 20-30 years Python may very well be added to that list (though less annoyingly capitalized). No one will have to rewrite their Python into whatever the new thing is then either. But not re-writing ProgramX into LanguageX+1 is not LanguageX's authors' problem or CompanyX-no-lo…

If they called Python 3 e.g. Cobra or Boa Constrictor or even Turbo/rapid/mega Python or similar nonsense, nobody would likely complain as it would clearly distinguish itself from existing ecosystem and all the enthusiasts could jump on the wave, boasting how much better it is, that it comes from the original authors of Python and then go through usual Darwinian selection to see if they prevailed. But breaking compat…

Yes they would. The apocalyptic doomsaying that would have happened if Guido had said "oh hey guys we're going to stop developing python here in a bit" would have been off the fucking charts.

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

#257
post #155
post #139

Earlier quoted context omitted.

Python 3.0 came out in 2008 and 3.3 came out in 2012. Are you really saying that nobody used Python3 for the first 4 years of its existence? I was certainly using 3.1 and 3.2 back then.

Django never had support for python < 3.3 and numpy and scipy only supported python 3.2 and up. The story is similar for most other packages. So if you where using python with any of its major libraries then python 3 was pretty much useless for you the first 3-4 years.

Django had support for 3.2 and 3.3, but not 3.0 and 3.1. Django didn't add support for 3.x until it was able to drop 2.5 (Feb 2013).

https://docs.djangoproject.com/en/2.0/faq/install/#what-pyth...

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

#258

Earlier quoted context omitted.

Blender was using py3k for quite a while before 3.3. I was doing blender dev work back then and can recall the almost immediate upgrades as soon as the newest python release came out -- kind of painful really since I prefered to use the fedora installed version instead of building from scratch so would often stall my dev work until fedora caught up to blender. They jumped on so early the python devs were saying "WTF…

Given blender is mostly c bindings and a huge code base, it's kinda impressive, and a good example that it's not an impossible task to migrate even a very hard project, let alone the most common ones.

It wasn't a migration as much as a bottom-up rewrite of the entire bpy and big chunks of blender itself. Most of the bindings are generated by makesrna at compile (compile compile?) time which is fairly simple once you go deep diving into the sources.

It actually takes a fair bit of shenanigans to get hand-coded bindings into blender, my last(?) patch was bindings for the kdtree and I had to do some convincing to get that accepted. I'd guess that 99% of bpy is generated bindings.

If they stuck with python 2 when they started the initial overhaul they'd probably still be using it since artists are very vocal when their scripts break.

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

#259

Earlier quoted context omitted.

> Your games don't work in windows XP anymore. In fact I can play EarthSiege 2, a game from the 3.11/Win95 era, just fine on Win7 x64 with the only things not working being joystick input (I guess it does some shenanigans with the MIDI/joystick port in addition to using the windows joystick API) and the pause screen which shows your vehicle spinning around spins too fast (probably because its speed is tethered to CPU…

Whenever this comes up I feel it is worth pointing out that Linux's "Things break" approach is a problem exclusive to the userland tooling built up around the kernel. Linus takes a very hardline stance against breaking kernel ABI compatibility (except for drivers), but pretty much every piece of software outside of that, including GLIBC, thinks it's totally ok to break things all the time. It's really very sad that t…

Even the kernel occasionally breaks interfaces. Case in point, FUTEX_FD was introduced in 2.6.0 and retired in 2.6.26 [1].

I don't think anyone working on glibc is intent on breaking user space. Sometimes it's just the most pragmatic solution.

[1] http://man7.org/linux/man-pages/man2/futex.2.html

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

#260

Any leaks/leads when Red Hat will announce RHEL 8.0?

> We're expecting to hear more about RHEL8 next month. Other current expectations are that Btrfs will be completely gutted in favor of the company's own Stratis Linux storage tech, the workstation session using GNOME on Wayland by default, shipping with the GCC 7 compiler, and possibly shipping with the Linux ~4.14 kernel. We're expecting an alpha sometime soon and would be perfect if announced at May's Red Hat Summit 2018.

https://www.phoronix.com/scan.php?page=news_item&px=RHEL-8-N...

Post reply on HN