Python Dispatch: Making the GIL Optional

The Steering Council have made a huge announcement regarding the future of Python. Namely, they have decided to make the Global Interpreter Lock (GIL) optional in CPython and eventually remove the GIL altogether.

This is a huge decision that will fundamentally alter Python.

Therefore, in this post, I’ll go through what the GIL is, its advantages and disadvantages, and what the future holds.

The GIL

Let me go through the Global Interpreter Lock one word at a time in reverse order, starting with lock and then interpreter and finally, global.

A lock is a mechanism that allows only one thread to run at a time. So when a thread gets ahold of the lock, it gains exclusive access to the Python interpreter.

An interpreter is the program for executing Python code.

The word “global” here refers to the scope of the interpreter lock. Because the interpreter lock is global, it guarantees that only one thread executes Python code at a time within a single process.

So the GIL is a mechanism that prevents multiple threads from running at the same time through the interpreter. But why would you want that?

Advantages

The primary advantage of the GIL is that it makes things easier. Managing memory is easier, managing threads is thus easier, and creating modules is thus easier.

Without the GIL, you can quickly run into problems with multithreading. If you don’t put the proper local locks into place for each thread, you might end up crashing Python or corrupting some other memory in the computer.

And if you’re not multithreading, then the GIL is super helpful, because it keeps everything running smoothly.

So the GIL keeps things simple and safe.

Then why wouldn’t you want that?

Disadvantages

The trade-off here is ease for speed.

By preventing multithreading, the GIL makes CPython slower and less performant than some other languages (like C++, Go, and Rust).

Especially with the explosion of AI in the past few months, the GIL is becoming more and more of a problem in executing programs quickly and efficiently.

The Future of the GIL

So now that the Steering Council have announced that they have accepted the Python Enhancement Proposal (PEP) 703, written by Sam Gross, we are entering uncharted waters.

Countless extensions have been written with the GIL in mind. All of the standards set with CPython depend on the GIL. Everyone builds in CPython with the GIL at the center of their programs (either intentionally or not).

Thus, the Steering Council are initially making the GIL optional, but in the long-term, they plan on phasing out the GIL completely.

As they put it in the post, “We do not want to create a permanent split between with-GIL and no-GIL builds (and extension modules).”

This will absolutely transform Python and, perhaps most interestingly, in ways that no one knows yet. Brett Cannon, in a poll to the core developer team, wrote that “making Python free-threaded… has a lot of unknowns. We don’t know how much code implicitly relies on the GIL, or thread-unsafe in subtle ways that are masked by the GIL.”

The GIL is disappearing – what will it take with it?

And, more importantly, what will the new CPython look like?