What is PEP 703 (free-threaded / no-GIL Python), and what does it change?
Quick Answer
PEP 703, implemented as an **experimental build option starting in Python 3.13** (`python3.13t`), removes the Global Interpreter Lock, replacing coarse-grained global locking with finer-grained per-object synchronization (including biased reference counting) so multiple threads can execute Python bytecode truly in parallel. It aims to make `threading` a viable path to real multi-core speedups for CPU-bound Python code, but as of 3.13/3.14 it's opt-in, carries a single-threaded performance cost, and the C-extension ecosystem is still catching up.
Detailed Answer
What changes
# Standard build -- has the GIL
python3.13 my_script.py
# Free-threaded build -- experimental, no GIL
python3.13t my_script.py
In a free-threaded build, the single global lock is replaced by finer-grained mechanisms: biased reference counting (a fast path for the common case where an object is only touched by the thread that owns it, falling back to atomic operations when shared across threads) and per-object or per-data-structure locking where needed, instead of one lock protecting everything.
The practical implication: threads can now use multiple cores
from concurrent.futures import ThreadPoolExecutor
def cpu_heavy(n):
return sum(i * i for i in range(n))
with ThreadPoolExecutor(max_workers=4) as pool:
results = list(pool.map(cpu_heavy, [10**7] * 4))
# on a free-threaded build, this can now actually run ~4x faster;
# on a standard GIL build, it doesn't (see the GIL question)
This is the headline benefit: CPU-bound pure-Python code using
threading/ThreadPoolExecutor can see genuine multi-core speedups
without needing to switch to multiprocessing and its IPC/pickling
overhead.
The tradeoffs, as of Python 3.13/3.14
- Single-threaded performance cost: removing the GIL's cheap global lock in favor of finer-grained (sometimes atomic) operations adds overhead to single-threaded code — early free-threaded builds showed a measurable (though steadily improving) single-thread slowdown compared to the standard GIL build.
- C extension compatibility: many existing C extensions assumed GIL
protection for their own internal state and need updates
(
Py_mod_gilslot, thread-safety audits) to be safe under free-threading; the ecosystem is actively migrating but not fully there yet. - Still opt-in: the GIL-enabled build remains the default and officially supported configuration; free-threading is offered as an alternative build for testing and gradual adoption, not (yet) the default for everyone.
Why it matters for interviews
It's a live, actively-evolving area of CPython — a good signal that a candidate follows the ecosystem, understands why the GIL existed in the first place (reference-counting safety), and can articulate what replacing it actually requires (finer-grained locking, not just deleting a mutex).
Interview-ready summary: PEP 703 introduces an experimental, opt-in build of CPython (3.13+) that removes the GIL via finer-grained synchronization (biased reference counting plus targeted locking), enabling real multi-core parallelism for threaded CPU-bound code — at the cost of some single-threaded overhead and an still-adapting C-extension ecosystem, which is why it isn't the default build yet.