Earlier quoted context omitted.
> "Most popular" packages, which ones? Most moved a long time ago to Python 3 http://py3readiness.org/
Thanks for proving my point There's Fabric3, MySQL libs that work with Python3 (and Django), futures are a backport of a feature from Python3, uWSGI and BeautifulSoup might be worrying but the site shows mostly green At this point if the library hasn't been ported to Py3, someone else would have done it for you or abandoned it. Edit: Thanks for the updates!
Python 2 will be replaced with Python 3 in the next RHEL major release
41–50 of 341 posts
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#42Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#43This links to the release notes for RHEL 7.5, which was released today, and is a minor release (in RHEL terms).
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#44If 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'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…
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#45Earlier quoted context omitted.
> "Most popular" packages, which ones? Most moved a long time ago to Python 3 http://py3readiness.org/
Thanks for proving my point There's Fabric3, MySQL libs that work with Python3 (and Django), futures are a backport of a feature from Python3, uWSGI and BeautifulSoup might be worrying but the site shows mostly green At this point if the library hasn't been ported to Py3, someone else would have done it for you or abandoned it. Edit: Thanks for the updates!
uWSGI has Python3 support as a module.
I have been using both on Python3 for many years. I don't think there is any python module left which does not have Python3 support or a more modern, better alternative.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#46They're two different languages. I don't see why python3 "replaces" python2 anymore than say ruby does. IMO they should have separate namespaces and invocation.
You can write code that runs with both python3 and python2. Therefore I wouldn't call them different languages.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#47Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#48Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#49Earlier quoted context omitted.
Thanks for proving my point There's Fabric3, MySQL libs that work with Python3 (and Django), futures are a backport of a feature from Python3, uWSGI and BeautifulSoup might be worrying but the site shows mostly green At this point if the library hasn't been ported to Py3, someone else would have done it for you or abandoned it. Edit: Thanks for the updates!
I think ansible is a big one for RHEL though.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#50Earlier 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…
Counter-example: The ruby 1.8 -> 1.9 -> 2.0 upgrade path. 1.9 introduced the whole encoding system, which was a major update at the time. It did break a lot of libraries that handled strings. Still, the change went over fairly quickly, partly because major players in the ruby world (rails) adopted the change. The update also brought clear benefits and it was clearly marked that 1.8 was going to go out of support. There are still some stragglers (centos 6, I'm looking in your direction), but it's clearly accepted that ruby 2.x is the standard that you should be writing code for.