Free-threaded Python: past, present, and future [LWN.net]
LWN<br>.net<br>News from the source
Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments
LWN FAQ<br>Write for us
User:<br>Password: |
Log in /<br>Subscribe /<br>Register
Free-threaded Python: past, present, and future
[LWN subscriber-only content]
By Jake Edge<br>June 22, 2026
PyCon US
Probably the biggest change for Python over the last five years or so is<br>the advent of the "free-threaded" version of the language, which removes the<br>global interpreter lock (GIL) and allows multiple threads to run in<br>parallel in the interpreter. At PyCon<br>US 2026, held in Long Beach, California in mid-May, longtime CPython<br>core developer (and current steering council member) Thomas Wouters gave a<br>talk about the feature. He looked at the motivation behind the GIL-removal<br>efforts, some history,<br>the current status of the free-threaded interpreter, and provided a<br>prediction on where it all leads.
Keep up with Linux and free software with a free trial subscription to LWN, no credit card required.
He began by noting that he has been doing CPython core development for<br>about 25 years at this point and has been on the steering council for five<br>of the last six years. The steering council is the body that determines the<br>path forward for language features, including free threading. Beyond that,<br>he works for Meta on the free-threaded interpreter and other things. While<br>it was not entirely relevant to the talk, he noted that he has three cats,<br>while putting up slides to show them. "In an alternate universe, there's<br>a version of this talk where I use my cats as my slides", he said to<br>laughter and applause.
Motivation
But, this is not that talk, he said; "this is a boring talk". While<br>he noted that most in the audience probably already knew, he quickly<br>introduced threads. They provide a way to execute multiple things at the<br>same time in a single process and its address space using separate<br>"threads of control". The primary reason that threads exist is for<br>performance; memory access is slow, so threads are a way to give the CPU<br>something else to do while waiting for memory.
The same benefit can come from using multiple processes, but there is more<br>overhead and the address spaces are not shared. There are some additional<br>reasons, beyond performance, that a language like Python needs threads.<br>For example, continuing to execute the main program while calling into<br>blocking APIs or when interacting with a third-party library that requires<br>using threads to access it, "commonly databases".
The GIL is "how CPython decided to support threads" a long time ago,<br>predating his involvement with the language. The GIL protects Python<br>objects and their reference counts, which are used to determine if the<br>objects are still in use; it also protects CPython internals and is "the<br>most efficient way that CPython can support threads". The GIL does not<br>protect a user's Python code because the user does not have control over<br>when the interpreter releases and reacquires the GIL. It "mostly does<br>not protect" C and C++ extensions either, even though it is clearer<br>when an extension call might release the GIL, "but it's still very easy<br>to unintentionally rely on the GIL and end up not being safe".
"Fundamentally, threads are hard"; they are complicated and the GIL<br>does not make them any easier, Wouters said, even though it seems like it<br>does at times. But the GIL also makes threads less useful, which is why<br>there have been efforts to remove it from Python over the years. When the<br>GIL was first added, multi-CPU systems were rare; now his phone has eight<br>cores.
For a long time, the alternative has been to rewrite parts of the program in<br>C, though for the last few years, that has been changed to Rust, which is<br>better. That answer does not always work, however; it means that much of<br>the application needs to be reworked to not only switch the code to the new<br>language, but also to switch the data into that language's domain.
There are other options, such as using multiple processes, but that typically<br>requires more memory and copying data between the processes. Subinterpreters will allow a single process to<br>have multiple interpreters, each with its own GIL, that can be run in<br>separate threads, but there some problems with using that approach. The<br>interaction with third-party libraries, especially those that are not<br>written with Python in mind, "isn't there yet" and there is no good<br>way, so far, to copy data between the subinterpreters. There is also asyncio,<br>which is effectively the same idea as green threads. He is<br>a big proponent of asyncio and thinks it is the best way to do<br>network I/O, "where threads can easily lead<br>you wrong".
But sometimes those solutions do not provide the performance needed, he<br>said. "Without the GIL, multi-threaded solutions to those things can<br>offer higher throughput, lower memory use, and lower latency." But, as<br>mentioned, threads are difficult. That is...