Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

access.redhat.com

Post reply on HN
Print view View original

231–240 of 341 posts

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

#231

Post by abritinthebay »

bjt2n3904 wrote: post #213
Narann wrote: 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…

Hello from the embedded world! The web world indeed can rapidly change their entire stack from LAMP to MEAN to Dockerized Q-Basic CGI scripts and load balance their Twitter clone. There's challenges for sure, but pushing updates is simple and quick, and you can always throw more cloud if you run into walls. If your complete platform rewrite fails, just roll the load balancer back over and try again tomorrow. It's a l…

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

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

#232

Post by dagmx »

Narann wrote: post #95
dajonker wrote: 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…

The CG industry (atleast for vfx) is moving to python 3 starting next year. Python 3 is part of the cy2019 reference platform.

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

#234

Post by vetinari »

sametmax wrote: post #194
vetinari wrote: post #162

Earlier quoted context omitted.

Actually, Android doesn't break the API, even by changing the definition of permissions. If you have a breakage, investigate your app manifest, what API version you are targeting. Android frameworks shim the old behaviors for the apps that declare the use of the old API versions.

E.G: Since API Level 19, the Alarm system has been completely remade. One must check the API Level to act some how or some differently. The same is for permissions after the advent of Android OS 6.0+. But we still need the support library to give Fragments and the ActionBar to API Levels lower than 11. And VectorDrawables to API Levels lower than 23. And many more objects. It's not that simple.

The shims are managed by targetSdkVersion, i.e. if you declare targetSdkVersion >= 23, you will get the new permission system (because it was introduced in 23) if running on [23,maxSdkVersion] device; if it is running on device that has API level [minSdkVersion,23), you get the old one; if you declare it The targetSdkVersion says what you designed against. If you claim supporting the new API, you should handle the new API (and that includes detecting what the underlying device supports). That does not preclude you from including the support library needed for lower API levels still supported.

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

#235

Post by Freaky »

irishsultan wrote: post #58
hyperpallium wrote: post #27

Earlier quoted context omitted.

I think it's the opposite. When other languages make incompatible changes, they have serious problems (e.g perl6). Previous versions of python were back-compatible. Java versions stress back-compatibility. I don't know if HN can find any counter-examples, of a language that thrived through an incompatible, code-breaking upgrade. Python has done everything possible to avoid this fate, by maintaining 2.7. And I'm not e…

> I don't know if HN can find any counter-examples, of a language that thrived through an incompatible, code-breaking upgrade. Ruby qualifies, I'd say. From 1.8 -> 1.9 there were syntax changes, changes to how strings worked and so on. Code written for 1.8 would not in general work on 1.9 and the other way around. While it was possible (sometimes with some extra if statements) to write code that worked on both versio…

It's notable that 1.9 came with a significant performance boost, so there was a good practical reason to want to upgrade. People were motivated by the prospect of their code running twice as fast - sure, the language was improved a bit too, but it's Ruby, it's already pretty nice, so that was hardly going to light a fire under anyone.

When Python 3 turned up and it was on average slower, my first thought was "well, good luck getting people to adopt that".

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

#236

Post by metalliqaz »

mkj wrote: post #12

Anyone know if /usr/bin/python will point to python3?

Even though it obviously still works, using "python" is no longer the recommended way to launch Python applications. You are supposed to use "python2" or "python3" if you care about which version you run with.

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

#237

Post by welder »

This is good, but it's sad that #!/usr/bin/env python will no longer work as the go-to shebang since python won't exist, only python3 will exist by default.

Geofft[1] has a nifty solution but it's not as cross platform as the old tride-n-true #!/usr/bin/env python:

#!/bin/sh """"type python3 >/dev/null 2>&1 && exec python3 "$(readlink -f "$0")" "$@" #"""

""""exec python "$(readlink -f "$0")" "$@" #"""

[1] https://ldpreload.com/blog/usr-bin-python-23

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

#238

Post by gsich »

gspetr wrote: post #193
mschuster91 wrote: post #156

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…

We can trade anecdotes on which games age well on which OSes all day. https://en.wikipedia.org/wiki/Chaos_League Released in 2004, you can't play on anything but Win XP because of Starforce DRM that didn't bother to patch for future compatibility.

I'm sure there is a community created solution for this. (a nice description of a "crack")

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

#239

Post by oblio »

UncleEntity wrote: post #230
oblio wrote: post #148

Earlier quoted context omitted.

They were breaking many things, maybe they should have rewritten the C API? From what I remember that's the blocker. That would have broken all C extensions, but it's not like Python 3 at launch was a raving success regarding library porting.

They did break all C extensions in py3k -- not so bad you can't work around it with some preprocessor magic but break it they did. And they continued to break them within the py3k lifetime, mostly unicode related stuff from what I can remember. Probably still break stuff but I haven't had time for my toy python projects in a while so haven't been messing with the C-API lately.

We're actually agreeing here, I think.

I wished they had broken everything harder and once and for all, in order to fix the issue.

If there's going to be breakage anyway, people adjust their expectations. The scale is basically:

a lot of breakage > a bit of breakage >>>>>> no breakage.

Once you do break backwards compatibility, you might as well do it in a big way, provided you:

* don't offer vaporware for a decade (hello Perl 6!)

* try to offer some mitigations for the migration pain (auto-conversions, support libraries, top-notch docs, etc.)

* offer a great carrot at the end of the tunnel (good performance would be such a carrot)

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

#240

Post by Avshalom »

bitL wrote: post #222
Avshalom wrote: post #206

Earlier quoted context omitted.

yeah and 90% of business code is also written in COBOL and another 90% in MUMPS, but somehow the world continues to work despite the fact that they've been pining for the fjords for decades.

There is obviously a massive jump from COBOL to Python, and small but annoyingly incompatible step from Python 2 to Python 3. I hope you understand the difference. It's not like Python 3 was the best language ever, it's just a variation (and IMO not that great one to justify breaking backwards compatibility) of the same theme. Ask Perl guys how they liked a similar situation. If I didn't need to use Python, I wouldn'…

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-longer-using-LanguageX's problem.

Post reply on HN