Live data from Hacker News

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

access.redhat.com

51–60 of 341 posts

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

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

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.

> No other living language could have gotten away with such ridiculous fragmentation and perf regression for such a long period of time

FTFY. Just think about Perl6, Lua5.3 and VB.NET

I am pretty sure somewhere in this world a miserable soul has to maintain a Ruby1.8 codebase.

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

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

On the one hand... This is 3 years after the first time I saw a Gentoo python3 only environment.

On the other Python2 support will go away when the community is done with Python2. And that process goes a lot slower than I think most people appreciate. Still, a big vendor changing their defaults helps a good deal with the push.

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

#53
post #13

Several shared-hosting companies don't support Python 3 yet. HostGator's default Python is still 2.6.

Python applications are second class citizens at HostGator and other cheap hosting services. Most people using Python applications are using VPS, containers or PaaS because deploying Python applications is a lot harder than just "drop the files" somewhere like it is with PHP.

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

#54

Earlier quoted context omitted.

I've found that if I set my default Python version to a Python 3 virtual environment, it breaks some system tools on my Fedora system (probably just because my virtual env doesn't have the necessary libraries installed, though I haven't tried to install them to test). Specifically gnome-tweak-tools, but probably others that are built with Python. Sort of a funny quirk. That's not me saying "don't use virtual environm…

This is strong evidence that something is set up wrong in your system. pyenv doesn’t change /usr/bin/python. If an app is using your PATH to find python it is going to break.

The apps in question use a shebang of `#!/usr/bin/env python3`. I believe it is working as designed. This is a Fedora system, which switched to Python 3 a couple of revisions back. But, I would assume this would affect any system that has utilities that use that shebang.

Edit: Out of curiosity, I grepped for other system utilities that might have this quirk, and it seems like nearly all Python utilities call /usr/bin/python3 directly, but ten of them (on my system) use `env`. That might be a bug worth filing with the Fedora folks. I can't imagine they want it to act this way when a custom Python is installed. Though it's been that way for at least a couple of releases.

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

#55
post #46
post #32

Earlier quoted context omitted.

You can write code that runs with both python3 and python2. Therefore I wouldn't call them different languages.

By that logic, C and C++ shouldn't be called different languages.

They share a special relationship, don't they? The difference to Python is though, that you're restricting yourself A LOT more when writing C and C++ compatible code (you're basically writing C with a few exceptions).

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

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

What's amazing is that pip3 gladly downloads and tries to install py2 stuff. Because package/dependency management is a complete afterthought in Python.

And sure, it'll get better, and finally we have lockfiles (Pipenv), and maybe eventually a proper SAT solver will help resolving dependencies https://github.com/pypa/pip/issues/988#issuecomment-36084645... , aaand gradual typing is nice too, and maybe eventually we'll have a proper async library (python-trio, as asyncio is there, but not low level and/or not ergonomic enough).

Yet Python is free and open, and amazing, and I haven't contributed much other than report bugs, so I'm not complaining, just comparing to other ecosystems.

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

#57

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.

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…

> Java versions stress back-compatibility.

You reminded me of the java version incompatibility nightmares that once littered the enterprise landscape. If they do that now, it's because their history includes perhaps the worst set of incompatibility jumps of any popular language.

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

#58

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.

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 versions I would definitely call it an incompatible, code-breaking upgrade.

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

#60
post #46
post #32

Earlier quoted context omitted.

You can write code that runs with both python3 and python2. Therefore I wouldn't call them different languages.

By that logic, C and C++ shouldn't be called different languages.

To a certain extent, they aren't.

The same compilers and tools are used for both, many developers mix the two in one codebase, and use small features from C++ in "C programs" because the compiler allows them to. For example before recent C standards, function overloading by argument types or declaring variables in the middle of a function.

But Python2 and Python3 are way more similar than C and C++.

Post reply on HN