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

161–170 of 341 posts

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

#161

Post by arunix »

Y_Y wrote: post #14
VeejayRampay wrote: post #5

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.

Not to mention the loss of tuple unpacking in function signatures. Even if i felt morally wrong about it, for the last few years I've been writing python2 with a few `from __future__`s at the top since it was fastest and most featureful and had all the libraries.

In case anyone wonders why tuple unpacking was removed:

https://www.python.org/dev/peps/pep-3113/#why-they-should-go

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

#162

Post by vetinari »

sametmax wrote: post #140
toyg wrote: post #135

Earlier quoted context omitted.

Sometimes I wonder if the opensource movement, with its perennial “update anxiety”, is actually busy generating an industry of legacy maintenance. In a way, it’s a natural extension of the original “development is free but you pay for support” idea, but I don’t think anyone openly elaborated it into a long-term revenue-generating strategy. It looks like a slam-dunk, to be honest, with the only caveat being that work…

It's not the opensource movement. It's IT in general. A lot of software stopped working with the windows 10 update that was forced on the users. Android breaks the API regularly by changing the permission game. The PSF has limited resources (3 million of dollar of budget) to exists (this includes running pypi and organising pyconf), but I think it's track record is quite good, even comparing to commercial products.

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.

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

#163

Post by goatlover »

nothrabannosir wrote: post #15
VeejayRampay wrote: post #5

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.

Double standards by whom?? Every other article or comment I’ve read since basically py3+1y has been incredibly negative about it. The only positive news about Python, recently, seems from people who were not around since the py2 days. Data science is where it’s at now, but it used to be massive and ubiquitous. Golang came at a time where public perception of Python was down the drain, and ate a big chunk of its lunch…

> and ate a big chunk of its lunch

Pretty sure that's not true. Golang might have taken some from Python web frameworks or command line tools, but that's about it. Python's popularity in scientific computing has only grown over time, and that encompasses a lot of fields and users, not just data science.

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

#164

Post by beagle3 »

pas wrote: post #56
ror6ax wrote: 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'l…

Conda has a silver and has been available for however many years. It also works well with pip.

Among people complain about python package management, I have never heard an argument against Conda other than “I don’t like that they recompile base python”. What’s your reason to discount conda?

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

#165

Post by kalefranz »

physicsguy wrote: post #159
afarrell wrote: post #87

Earlier quoted context omitted.

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

You can install things with pip but you have to be really careful, because Conda tries to do clever things to avoid downloading multiple copies, which is what you end up with in Virtualenvs. So, if you have two environments both using the same version Jupyter version, installed with 'conda install jupyter' it will only have one copy which is symlinked into the environments. Problem is, if you do 'pip install' in one…

The pip that conda and conda-forge install now have a two-line patch that fixes this. Newly fixed within the last month or so. (It's in our queue to push it further upstream.) Just make sure you `conda update pip` instead of `pip install -U pip` and you'll be fine now.

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

#166

Post by badsectoracula »

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…

Projects that need to continue using 2.7 can use a fork that promises to preserve backwards compatibility like Tauthon:

https://github.com/naftaliharris/tauthon

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

#167

Post by kalefranz »

beagle3 wrote: post #164
pas wrote: post #56

Earlier quoted context omitted.

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'l…

Conda has a silver and has been available for however many years. It also works well with pip. Among people complain about python package management, I have never heard an argument against Conda other than “I don’t like that they recompile base python”. What’s your reason to discount conda?

Our python is compiled with the latest versions of gcc (on Linux) and clang (on macOS). So you're getting gcc 7.2 compiled python on RHEL/CentOS 6. And all of the security and performance enhancements that come along with it [1]. (Ok we're still on 7.2; we'll update to 7.3 in the next couple months.)

[1] https://www.anaconda.com/blog/developer-blog/improved-securi...

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

#168

Post by kalefranz »

kalefranz wrote: post #167
beagle3 wrote: post #164

Earlier quoted context omitted.

Conda has a silver and has been available for however many years. It also works well with pip. Among people complain about python package management, I have never heard an argument against Conda other than “I don’t like that they recompile base python”. What’s your reason to discount conda?

Our python is compiled with the latest versions of gcc (on Linux) and clang (on macOS). So you're getting gcc 7.2 compiled python on RHEL/CentOS 6. And all of the security and performance enhancements that come along with it [1]. (Ok we're still on 7.2; we'll update to 7.3 in the next couple months.) [1] https://www.anaconda.com/blog/developer-blog/improved-securi...

P.S. If you're looking for a latest and greatest C/C++ compiler toolchain that's backed with "production" testing via hundreds of millions of package installs and works on older versions of linux...

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

#169

Post by kalefranz »

oblio wrote: post #68
lunchladydoris wrote: post #21

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.

> doesn't play well with Pip

The focus of my current right-now dev work is to teach conda to better understand non-conda-installed python packages so we respect what's already there even if it's not a conda package.

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

#170

Post by oblio »

kalefranz wrote: post #169
oblio wrote: post #68

Earlier quoted context omitted.

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.

> doesn't play well with Pip The focus of my current right-now dev work is to teach conda to better understand non-conda-installed python packages so we respect what's already there even if it's not a conda package.

That would be a humongous boon, especially for Windows. I really wanted to use Conda, but I really, really needed Pip for packages. I don't really remember what blew up when I tried it, but it wasn't pretty.

Glad to know that soon enough that will be just a memory :)

Post reply on HN