Python's free-threaded build is inching toward mainstream
CPython has shipped an experimental "free-threaded" build since Python 3.13 — a version of the interpreter, defined by PEP 703, that removes the Global Interpreter Lock entirely. It's still opt-in and still labeled experimental, but it's the first time in Python's history that multiple threads can execute Python bytecode at the same time on multiple cores, rather than taking turns.
Why the GIL mattered in the first place
The Global Interpreter Lock has always meant that even on an 8-core machine, only one thread runs Python code at any instant — threading gave you concurrency for I/O-bound work (waiting on network calls, file reads), but never true CPU parallelism. Anyone who needed to actually use multiple cores reached for multiprocessing instead, with the overhead of separate processes and serialized data between them. Free-threaded Python is the first real path to skipping that workaround.
What's different in practice
python3.13t --version
The t suffix marks the free-threaded build — it installs alongside the regular interpreter rather than replacing it, specifically so existing code and C extensions that assume a GIL keep working unaffected. Pure-Python threaded code gets the parallelism for free; C extensions need to explicitly declare themselves thread-safe to benefit, and plenty haven't yet.
What "experimental" means here
This isn't a build to switch production workloads onto yet. Some C extensions crash or behave incorrectly under it until their maintainers add explicit thread-safety support, and single-threaded performance takes a measurable hit compared to the standard build — the trade made in exchange for removing the lock. The core team's own stated plan is a multi-release path toward making it a fully supported, non-experimental option, not an overnight switch.
Worth trying if
You've got CPU-bound Python code currently split across multiprocessing purely to get parallelism, and you're curious what it looks like without the process-boundary overhead. It's a good build to experiment with on a side project now — the interpreter is real and installable, the story is just not "swap this into production" yet.
Source: peps.python.org