Live data from Hacker News

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

access.redhat.com

81–90 of 341 posts

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

#81
post #76
post #64

Earlier quoted context omitted.

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

> a_list = [] # type: List[T]

How do you do that with out a comment?

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

#82

Earlier quoted context omitted.

yes and it took me a while to fix things. I still need to maintain my python2 code

Doesn't OSX come with python2 by default?

It does, what can break is what `python` points to.

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

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

RHEL's system tools like yum use python2 today, but in the next release will rely on python3.

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

#84
post #42

Let's hope this will finally change the "compatibility with py3 is a feature" to "no py3 compatibility - no library" state of things. It's really surprising how stubborn some teams are.

It's time!

It's really irritating in the scientific programming world at the moment because we've had some dependencies take years to get to Python 3 compatibility and are they're now being all holier than thou about it all.

We couldn't even start doing the work until our biggest dependency (which we use in 90% of the code base) was ported to Python 3 and while that's been available for about a year, they weren't distributing it and you had to compile from source to get the Python 3 version - and compiling this particular package, which shall remain nameless, is one of the most difficult compilations I've ever had the misfortune to try. It's notable by it's absence on the UK national supercomputer because of this, for example.

So now, we're trying to port our code to it, but it's likely going to take 6 months to a year to do so. Our day job is doing scientific research, and that's what brings in grant income - so for us, it's not a huge priority to spend all our time working on the switch to Python 3, because we can run everything in a Docker container with fixed dependencies and it should continue to run fine for the next 10 years. It will happen, it's just not the most important thing on our list.

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

#87
post #68

If this is an issue for you, I would highly recommend that you have a look at virtual environments via tools like virtualenv and conda. That way you'll be able to run all the versions you like.

I tried this a while ago. I think Conda allows installing different versions of Python (good) but it doesn't play well with Pip (bad)? Last I tried it also bundled dependencies in its own particular way (ugly)? I think it was more geared towards SciPy and NumPy and other scientific development than towards general purpose programming.

> I think Conda allows installing different versions of Python (good)

Yep. Also allows installing different versions of node or ruby.

> Doesn't play well with Pip (bad)

You can `pip install` things into a conda environment but I forget how it works with globally pip-installed packages. I don't think it plays nicely with virtualenv.

> Last I tried it also bundled dependencies in its own particular way (ugly)? I think it was more geared towards SciPy and NumPy and other scientific development than towards general purpose programming.

Yep, it was made by the maintainers of SciPy and NumPy to solve the problem where you have a python package that depends on a system library written in c/fortran/IDL. For an example in ruby, see the problems people have with charlock_holmes: https://stackoverflow.com/search?q=charlock_holmes

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

#88
post #76

Earlier quoted context omitted.

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

> a_list = [] # type: List[T] How do you do that with out a comment?

> a_list: List[T] = []

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

#89
post #79
post #75

Earlier quoted context omitted.

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.

Uhhhh... sort of? I mean, I could go through all of the needless "why the hell did they make this partner incompatible also" stuff like, like removing u'' support (thai was added later), or all of the ludicrous breakage in the underlying APIs (like filesystem calls that made assumptions about character encoding that make no sense for the underlying Unix model and literally caused files to just disappear from iteration)... a lot of this stuff was fixed in later versions of Python 3, but that was years later, making it nearly impossible to deal with the existing land mines of people who had installed Python 3.0-3 (or even 3.4).

But what makes me shocked that you think that that is the case is basic basic stuff... I mean, as one obvious example, they changed the exception syntax. So, "uhhhh.... sure?" it was possible to make a program that ran on both 2 and 3, but it required using "try" with no variable assignment and then digging into Python's exception reflection support to recover the variable. And you had to do this every single time. (And of course a lot of the time the underlying core library would now throw different exceptions, making the situation all the more ludicrous.)

I had code that straddles the 1.8/1.9 boundary of Ruby, and even though I wasn't an expert at Ruby it was trivial to have code that worked for both (and I mean 100% correct: Unicode and everything; remember that neither Ruby 1.9 nor Python 3 added Unicode support, they only made Unicode support easier to obtain. for Python 2 there was already comprehensive, if non-default, support, and for Ruby 1.8 you just needed to be careful about where you did conversions).

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

#90
post #76

Earlier quoted context omitted.

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

> a_list = [] # type: List[T] How do you do that with out a comment?

a_list: List[T] = []
Post reply on HN