The GIL sucks.

"Just use a non-GIL implementation!"

Which? The one stuck on 3.4 or the one stuck on 2.7?

"Just use multiprocessing!"

Just hit a nail in with a pile driver!

I used to think like this too, before I stopped caring 🤔

What's wrong with multiprocessing?

It sounds ... Interesting.

https://python.org/dev/peps/...

Is an approach but it's still draft though 3.10 is approaching

AsyncIO as an alternative?

I have a solution: just don’t use python at all

@iiii Latency, overhead, missing fork on windows (=> further increased latency and some objects cannot be passed).

Stackless Python might do what you want, but really if you're going this way you might want to switch to a language better suited for this kind of stuff.

Removing the GIL costs >10% per thread performance...

If you _really_ have to do parallel work in python you are likely doing something wrong - for computing tasks Python is just the wrong language. Use something like C / Cython / Rust / ... for it. Whenever calling non-Python code, the GIL should be released for the thread anyway, at least if the code is properly written.

@sbiewald still better than running everything in one thread.

What is wrong with Python 3.4? It isn't that old, only 7 years. You should not use the new fancy stuff in real projects anyway, and wait till it is properly tested. And no, that isn't old for a programming language version, be a bit more conservative.

@happygimp0 Python 3.4 is EOL since 2019. As the GILless built of it likely depends on CPython, it will not get any security fixes..

On "do not always use the latest language features" I partially agree, but looking at how widely Python is used, I somehow doubt the new features aren't 'tested enough'.

@sbiewald Ok, in this case i think Python EOL is way too soon for a programming language. Compare it to languages like C.

C and Python have different uses. I think 7 years to EOL a scripting language is alright.

@sbiewald The fact that this feature is still not implemented in any newer version of Python is an argument that the newer versions aren't old enough.

@happygimp0 The problem with Python is the not-so-clean distinction between "language standard" and "implementation".
The de-facto standard implementation is CPython - it is the reference implementation of the latest language version. By definition, a "language standard" cannot be EOL, but also won't be changed.
By the way, the GIL is not part of the language standard, its an implementation detail of CPython.

While there are a few implementations independent of CPython (PyPy, Jython, IronPython), some are just a fork (Stackless, some "CPython without GIL" ones).
Only the CPython forks (and mostly PyPy) do have a compatible extension interface with CPython (and libraries requiring this interface are common).
And CPython releases (and usually the forks) will not get any update five years after the initial release.