https://stefan-marr.de/2023/06/...

Fascinating.

So I saw they might be able to remove the GIL for real in Python the other day. However, now they are thinking it will take a long time to make sure all the current libraries behave correctly when it is removed. They are concerned the libraries current implementations might in some parts be dependent on the GIL being there. But this also isn't the first time I have heard they "might" be able to remove the GIL.

@Demolishun pypy doesnt have GIL right?

@retoor I don't think it has a GIL. I am not sure it can run every python program either. I think they sacrificed some things for speed and JIT compiling.

Not entirely sure how we came to GIL....

https://doc.pypy.org/en/latest/...

PyPy has a GIL.

https://peps.python.org/pep-0703/

The GIL removal is happening though.

In baby steps, by making it first optional, but it's happening.

The trouble with the removal is that it is one of these "bomb the foundation away and let's see what's happening" kind of changes. The GIL is what made large parts of Python thread safe "by design" - as they couldn't be used by multiple threads.

Removing the lock means one now has to apply thread safety "by code". No more global lock means that a lot of code could now be accessed by multiple threads...

@IntrusionCM well, I got around it using multiprocessing anyway.

@Demolishun yes.

Though that is part of the problem (Trademark).

Multithreading / Multiprocessing is a manual intervention to circumvent the problem.

"if" python would be multithreaded by default, the general performance on multicore machines should be better by default - at the cost of a worse single core performance.

Single core designs have become "rare" - almost nonexistent.

While I understand the concerns of the Python Devs, I think it's overdue.

I don't think we will get back to single core machines - forever... The paradigm of single core designs is dead.

Time to bury the program paradigms, too.

@IntrusionCM I shouldn't have to spin up the interpreter multiple times. Yes, I think this will help keep Python more relevant in the multiprocessor age.

What is the "programs" paradigm?

@Demolishun bad wording.

I meant the coding paradigms.

A global lock was once a common coding paradigm as "SMP (Symmetric MultiProcessing) platforms are rare unicorns"...

Well. For 20 years plus, these rare unicorns are the norm, so we shouldn't use the coding paradigm of global locks anymore...

Programming paradigm - coding paradigm.