Comment by csmpltn | Hacker News Reader

Comment by csmpltn | Hacker News Reader

Parent Full thread

There are plenty of other Python VMs that don't have a GIL and can be used already today, out of the box (examples include Jython and IronPython). Despite that fact - CPython remains the most popular Python VM out there (it utilizes a GIL).

Instead of waiting for the GIL to be removed out of CPython - take your fancy Python code and just run it using a different VM. It's literally as simple as that.

If the GIL was such a bottleneck as people make it out to be - people would move off of CPython a long time ago. But they won't, despite having the options. This only serves to prove that 95%+ of the workflows people build with Python can be satisfied regardless of GIL, often using some of the other parallelism mechanisms available in Python today (multiprocessing, asyncio, etc).

Most of the stuff people build with Python are CRUD apps, Jupyter notebooks, automations, tinkering, small hacks, etc. If you're okay with not utilizing all of your 64k CPUs at home - Python's multiprocessing and asyncio libraries should serve you just fine.

The whole GIL/No-GIL conversation is a complete waste of time and a distraction. People have all the options they need already here and now - but slinging crap at eachother over an issue tracker is so much fun that people can't help it.

People stay on CPython due to the performance of C extensions and the vast ecosystem based on them. The fact that people have stuck with CPython isn't at all evidence that they like the GIL or that it doesn't lead to significant technical problems.

Besides the C extension issue, Jython is based on Python 2.7 and IronPython appears to be on 3.4. These aren't serious alternatives.

Not true. They're is GraalPython, which is for Python 3 and supports also native code extensions.

https://github.com/oracle/graalpython

What is not true? I don’t see what this is supposed to address in my post. I cited Jython and IronPython because that’s what the person I was responding to mentioned.

GraalPy looks neat, but is experimental/young still. Notably, it has a GIL specifically to be compatible with CPython.

Would a large codebase seemlessly run on another interpreter?

Not likely, particularly if you depend on modules written (partly) in C like numpy/scipy etc

I just did some searching around PyPy and that seems to be the case. IronPython is out of support now but the looks of it. Which is a shame. I heard of it 10 years ago, but assumed it was some "Microsoftized Python" and not at all a compatible thing :-)

The same happened to jython which is all but dead and stuck forever at python 2.7

If you stick to "pure Python" there's a larger chance you can use any python runtime and be able to run your code

I think you underestimate the problems that will occur in a large code base when the GIL is gone. It'll play out like this:

Test will be fine, but production will have some weird bugs. Nobody understands it. The devs end up adding locks everywhere, bringing down performance, or creating dead locks. In the end, they migrate back to Python 3.16.

Here's free lesson number 1: start adding stress tests now.

If you have a lot of code, there’s plenty of Internet drama to be had in moving to another runtime, too.

Reply on news.ycombinator.com