Python 3.14 makes free-threading official

Python 3.14 is out. Three things in it are structurally important and one of them has been thirty years coming.

free-threading is officially supported#

The GIL-free build, introduced experimentally in 3.13, is now an officially supported configuration. Not the default — you install python3.14t alongside the standard build — but supported, with a commitment to maintain it.

This is the largest change to Python's execution model since the language existed. The global interpreter lock has meant that CPU-bound Python code cannot use multiple cores in one process, which is why every CPU-bound Python program either uses multiprocessing (with its serialization overhead and memory duplication) or drops into C.

python3.14t -c "import sys; print(sys._is_gil_enabled())"
# False

The caveats are real and you should read them before getting excited.

Single-threaded performance in the free-threaded build is slower — the reference counting has to be thread-safe, and that costs. The gap has narrowed a lot between 3.13 and 3.14 and it has not closed.

C extensions must be explicitly compatible. Anything using the C API with assumptions about GIL protection needs auditing. The major numerical and data libraries have been doing this work for two years; the long tail has not.

And the hard part: your Python code is now actually concurrent. Race conditions that the GIL was accidentally preventing are now possible. Code that was "thread-safe" because bytecode operations were effectively atomic may not be. Nobody knows how much library code depends on this implicitly, because nobody has ever had to know.

Do not switch production workloads casually. Do start testing your libraries against it, because the compatibility work has to happen somewhere.

t-strings#

PEP 750 lands. t"..." produces a Template with the static parts and the interpolated values separated, rather than a concatenated string.

from string.templatelib import Template
name = input()
query = t"select * from users where name = {name}"
query.strings   # static segments
query.values    # (name,)

A library receiving a Template can parameterize the SQL, escape by HTML context, or quote for a shell — correctly, because it can still tell the difference between the template and the data.

The value depends entirely on library adoption. Watch the database drivers.

deferred annotation evaluation#

PEP 649. Annotations are no longer evaluated at definition time; they are computed lazily when something asks for them.

def process(items: list[Order]) -> Report:   # Order and Report need not exist yet
    ...

This kills from __future__ import annotations, kills most string-quoted forward references, and fixes the circular import problems that plague any codebase using type hints heavily across modules.

It also makes runtime introspection cheaper for the common case where nobody looks at annotations at all.

the rest#

• Multiple interpreters in the standard library (concurrent.interpreters), giving true isolation with lower overhead than processes.
• A new REPL with syntax highlighting and better multi-line editing.
• except without parentheses for multiple exception types.
• Substantially better error messages, continuing a multi-release trend that has made Python meaningfully friendlier to learn.

the assessment#

Python's response to being slow and single-threaded has, for two decades, been "call C." 3.14 is the release where the language stops accepting that as the answer.

Free-threading plus subinterpreters plus the ongoing specializing-interpreter work is a coherent strategy for making Python a reasonable choice for CPU-bound work. It will take several more releases and a lot of ecosystem effort.

It is genuinely happening, which is more than most people expected five years ago.