A Steering Council notice about PEP 703 (Making the Global Interpreter Lock Optional in CPython)

I really want to know that if the GIL being removed , my python program will autonomously use the multicore CPUs while i don’t have to use the multiprocess or asynio module?

You have to use the threading module (not multiprocessing or asyncio).

1 Like

I don’t see why removing the GIL, which many have fought with for years, need change the language syntax in any way whatsoever. It seems to me a cpython implementation detail. If I am right about that then there is no danger of incompatibility with existing python code. Thus I don’t see why wanting to avoid another Python 2 to Python 3 transition difficulty is relevant.

If this sore point of our favorite language can be removed from the implementation and if I am right about no syntax changes being necessary then I say by all means remove it as quickly as possible and have only a period of choosing to run with it remove that is short, say a year, before this sore point is gone from Python forever. I don’t see why anything like 5 years would be necessary.

1 Like

It’s not changing the syntax, it’s changing the C ABI, which is what native extensions are built against. It is not something that can be changed quickly or without careful planning and review along the way.

8 Likes

Closing as this is starting to get off topic again. This was meant as an announcement by the SC about the PEP, not further discussion about its feasibility or effects.

16 Likes