Live data from Hacker News

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

access.redhat.com

71–80 of 341 posts

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

#71

> next RHEL major release This links to the release notes for RHEL 7.5, which was released today, and is a minor release (in RHEL terms).

"Python 2 has been deprecated Python 2 will be replaced with Python 3 in the next Red Hat Enterprise Linux (RHEL) major release." So, deprecated in RHEL 7.5 as a fair warning to everybody and replaced with Python 3 in RHEL 8. You'd know this if you had actually read the linked release notes you mention. ;)

Ah. Still weird to say that "Python 2" is deprecated as of RHEL 7.5 when both the installation frontend and yum use Python 2.7.5, and Python 3 isn't even on the installation media.

(Grabbed the ISO and made sure the above assertions are true.)

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

#74
post #37
post #22

Earlier quoted context omitted.

I'm not sure that tuple unpacking in function signatures is any great loss. It's a feature I hardly ever saw used and if you do need to unpack an argument then you can do so in the first line of the function's code.

I saw it used a lot and it caused hours of rewrites to get libraries python3 ready. It's one of those things where I wonder why they didn't just depreciate it for another few iterations, allowing scripts to be changed over time.

The 2to3 tool will rewrite it automatically. It's not something that requires manual intervention.

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

#75

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…

The fact that it was possible to write code that worked with both wasn't just so critical, though. It allowed you to upgrade your code incrementally to support 1.9 while doing regression testing on 1.8, and then come up with a deprecation schedule for 1.8.

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

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

Since Python 3.5 (3 years ago) type hints are part of the core syntax. Don't need to put them in comments. https://www.python.org/dev/peps/pep-0484/#type-definition-sy...

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

#77
post #70
post #25

Earlier quoted context omitted.

That would be really bad. The new scripts should just use the right #! string

#!/usr/bin/env python2 There, fixed it. Much like `#!/usr/bin/env bash` for bash scripts instead of `#!/bin/bash` (which won't work on many OSes) https://github.com/search?q=%23%21%2Fusr%2Fbin%2Fenv+python2...

You can't "there fixed it" for the infinite number of projects that exist in the field that this breaks. "It never worked on FreeBSD" is very different from "it no longer works on new versions of RHEL".

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

#78
post #35
post #28

Earlier quoted context omitted.

They do -- it's trivial to have python2 installed on the same system as python3. The deal with RHEL is that they will no longer include python2 packages at all. That isn't really to say that somebody else won't make packages.

Thank you, that's much more clear. So RHEL is deprecating their python2 package i.e. declaring their intent to eventually remove it. For some reason "replaces X with Y" suggests to me that they swapped one for the other (e.g. /usr/bin/python) which seems error-prone.

There are things included in RHEL which use Python. These will now use Python3 instead of Python2, so from that perspective it has been replaced.

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

#79
post #75

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. 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…

The fact that it was possible to write code that worked with both wasn't just so critical, though. It allowed you to upgrade your code incrementally to support 1.9 while doing regression testing on 1.8, and then come up with a deprecation schedule for 1.8.

Python could be written that way (2/3-compatible) as well and plenty of programs and modules were.

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

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

> a bit lucky to catch the ML train

I'd argue that the fact that it was explicitly a design goal to be a teaching language meant that it saw wide-scale adoption by universities, which made it more likely that someone writing an adaptor library to old linear algebra packages would write it in python.

Post reply on HN