What happened
Python 3.14, released 7 October 2025, makes the free-threaded (no-GIL) build officially supported (PEP 779) — the second phase of PEP 703. The PEP 703 implementation is now finished, including C API changes; the specializing adaptive interpreter (PEP 659) is enabled in free-threaded mode; and the single-threaded performance penalty is down to roughly 5–10%. Free-threading still ships as a separate, opt-in build — the GIL-enabled interpreter remains the default.
Why it matters
The Global Interpreter Lock has capped CPU-bound Python to a single core for decades, pushing teams to multiprocessing, C extensions, or other languages. Removing it — as a supported option — lets threads finally run Python bytecode in parallel, which reopens the design space for data pipelines, ML preprocessing, and CPU-bound services.
'Officially supported' is not 'flip it on in prod.' The single-threaded tax is real, and the ecosystem is the gate: many C extensions aren't free-threaded-safe yet, and code that quietly relied on the GIL for atomicity can now race. The Staff move is to benchmark a genuinely parallel workload on the free-threaded build, audit native dependencies for support, and treat existing 'thread-safe because GIL' assumptions as bugs waiting to surface.
What did the GIL actually protect, and what breaks — or becomes possible — when you run CPU-bound Python on a free-threaded build?
Probes interpreter internals, thread safety, and concurrency trade-offs.