where free-threading actually stands#

The GIL-free build has been officially supported since 3.14. The question was never whether CPython could do it — it demonstrably can — but whether the ecosystem would follow.

What has gone well:

The major numerical and data libraries did the work. NumPy, and the array and dataframe ecosystem around it, ship free-threaded wheels. That was the critical path, because those libraries are the reason a large fraction of Python's CPU-bound workload exists.

Single-threaded performance in the free-threaded build has improved substantially since 3.13. The gap against the default build has narrowed to something most applications would not notice.

Build infrastructure caught up. Producing free-threaded wheels is now a configuration change rather than a project.

What has gone slowly:

The long tail. Thousands of packages with C extensions have not been audited, and most of them will not be until someone hits a problem.

The subtler issue: pure-Python code that was accidentally thread-safe. The GIL made many operations effectively atomic. Code written under that assumption — a dictionary mutated from multiple threads, a counter incremented without a lock — worked by accident. Under free-threading it does not.

Nobody knows how much library code depends on this, because nobody ever had to think about it. It will be discovered one race condition at a time.

the practical guidance#

Do not switch production workloads casually. The performance win only exists for CPU-bound multithreaded work. If your workload is I/O-bound, asyncio was already handling it and free-threading gives you nothing.

Do test your libraries against it. The compatibility work has to happen and it happens when people run into problems and report them. If you maintain a package with a C extension, this is your work to do.

Do use it for the workloads it is for. Data processing, image and signal processing, simulation, anything numeric that currently uses multiprocessing and pays serialization and memory-duplication costs.

The migration from multiprocessing to threads for those workloads is frequently dramatic — not just faster, but simpler, because you delete the serialization layer.

the other thing in 3.15#

Subinterpreters continue maturing. concurrent.interpreters gives you isolated interpreter instances in one process, with much lower overhead than processes and much stronger isolation than threads.

This is the underrated option. For a workload where you want parallelism and do not want shared mutable state — which is most workloads — subinterpreters give you the process model's safety at closer to the thread model's cost.

It is the right default for a lot of the cases people currently reach for multiprocessing for, and it does not require any of the thread-safety auditing that free-threading does.

Error messages continue improving, which has been a multi-release trend and has made Python meaningfully friendlier for people learning it.

the assessment#

Python is executing a decade-long project to stop being single-threaded, and it is doing it without breaking the ecosystem, on an opt-in basis, with a fallback.

That is the right way to do it and it is slower than anyone wants. The alternative — a hard break, a Python 4 — would have been faster and would have cost the community what Python 3 cost it, which nobody has the appetite for.

Ask again in three years. The trajectory is good and the destination is not in doubt; only the timeline is.

what it is#

Destructuring and dispatch in one construct: match a value against a shape, bind its parts to names, and branch on which shape matched.

Java:

String describe(Shape s) {
    return switch (s) {
        case Circle c when c.radius() > 100 -> "big circle";
        case Circle c                        -> "circle r=" + c.radius();
        case Rect(int w, int h) when w == h  -> "square " + w;
        case Rect(int w, int h)              -> "rect " + w + "x" + h;
    };
}

Python:

match command.split():
    case ["move", direction]:
        move(direction)
    case ["take", *items] if items:
        for item in items: take(item)
    case _:
        unknown()

Both are doing the same thing: testing structure, extracting components, and binding them, in one expression.

why it matters more than it looks#

Exhaustiveness checking. This is the actual payoff and it is easy to miss.

If your type system knows the complete set of possible shapes — a sealed hierarchy in Java, a union type in TypeScript, an enum in Rust — the compiler can verify that your match handles all of them.

Which means: add a new case to your data model, and the compiler tells you every place that needs updating.

That is a qualitatively different maintenance experience. Without it, adding a new variant means grepping for every switch statement and hoping. With it, the build fails until you have handled it everywhere.

This is the single largest practical benefit of algebraic data types and most discussion of pattern matching skips it entirely in favor of syntax.

It replaces the visitor pattern. An entire design pattern existed because object-oriented languages could not dispatch on structure. That pattern is a significant amount of ceremony — an interface, an accept method on every node, a visitor implementation — to express what pattern matching says in five lines.

If you have a visitor in your codebase and your language now has pattern matching, you can delete a lot of code.

It makes illegal states harder to express. Combined with sum types, you can model "this is one of exactly these things" and have the compiler enforce it, rather than a class with six nullable fields where only certain combinations are valid.

the caveats#

Python's match is not exhaustiveness-checked. It is a runtime construct. Without a sealed type system there is nothing to check against. Type checkers can do some of this with Literal and Union types and it is not enforced by the language.

That makes Python's version considerably less valuable than Java's or Rust's — it is nicer destructuring syntax rather than a correctness tool.

Capture semantics surprise people. In Python, a bare name in a pattern binds, it does not compare. This is the number one confusion:

match color:
    case RED:      # binds `color` to RED — matches everything!
        ...
    case Color.RED:  # this compares
        ...

A dotted name compares. A bare name binds. Everybody gets this wrong once.

Overuse. Pattern matching is satisfying and it is possible to write a match statement where an if would be clearer. If you are matching on one condition, use an if.

the trend it is part of#

Pattern matching is one of several ideas migrating from functional languages into the mainstream, along with immutability by default, expression-oriented syntax, Option/Result types instead of null and exceptions, and real sum types.

Each of these took decades to cross over. The reason is not that the ideas were unknown — it is that mainstream languages have compatibility obligations that make adding a feature to an existing type system extraordinarily hard, and it takes a generation of language designers who grew up with the ideas to do the work.

The next ones in the queue, visibly: effect systems, better concurrency abstractions in the type system, and some form of ownership tracking outside of Rust.

Give it ten years.

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.

This is a small feature with a large security implication.

the problem it solves#

F-strings are wonderful and they are the most common source of injection bugs in modern Python, because they make the wrong thing effortless:

# this is a SQL injection and it looks completely normal
cursor.execute(f"SELECT * FROM users WHERE name = '{name}'")

# so is this, for HTML
return f"<div>{user_bio}</div>"

The f-string evaluates and concatenates before the function ever sees it. By the time execute gets the string, the distinction between the query template and the user data is gone permanently. There is no way for a library to help you.

what t-strings do#

A t-string does not produce a string. It produces a Template containing the static text segments and the interpolations separately:

from string.templatelib import Template

name = "Robert'); DROP TABLE students;--"
t = t"SELECT * FROM users WHERE name = '{name}'"

type(t)          # <class 'string.templatelib.Template'>
t.strings        # ("SELECT * FROM users WHERE name = '", "'")
t.values         # ("Robert'); DROP TABLE students;--",)

Now a library can do the right thing. A SQL driver can turn the static parts into a parameterized query and bind the values. An HTML library can escape each interpolation according to its context — attribute versus text node versus URL — which is something no escaping function can do correctly without knowing where the value landed.

# a hypothetical driver that accepts templates
await conn.execute(t"SELECT * FROM users WHERE name = {name}")
# becomes: SELECT * FROM users WHERE name = $1, with name bound

The syntax is identical to an f-string. Format specs and conversions work. Nesting works. The only difference is the prefix and the type.

why this is the right design#

The alternative approaches all failed for the same reason: they required the developer to do extra work at the call site, and developers under deadline do the easy thing.

t"..." is exactly as easy as f"...". It is one character. And crucially, a function that expects a Template will reject an f-string with a type error — so a library can make the safe path the only path, and the unsafe call site becomes a build failure rather than a pentest finding.

That is the property that makes this work. Security features that depend on diligence do not scale. Security features that are enforced by the type system do.

what to watch#

The value of this feature is entirely downstream: it depends on library authors adopting it. Watch for template support in the major database drivers, the templating engines, the shell-command helpers, and the logging libraries.

If that adoption happens over the next couple of release cycles, a whole category of Python vulnerability quietly stops being writable. If it does not, this is a nice piece of syntax nobody uses.

Bet on adoption. The ergonomics are too good and the security argument is too easy to make to a security team.