Python 3.14: What's New and What Actually Matters

Seven months after Python 3.14 dropped, the dust has settled enough to say what actually matters. Some of the headline features turned out to be transformative in practice. Others are exactly as niche as they sounded in the PEP. This post cuts through both.

The version is stable on all major platforms, the ecosystem has largely caught up, and if you’re still running 3.11 or 3.12 in production, you have concrete reasons to think about a migration plan now.

t-strings: The Feature Library Authors Have Wanted for a Decade

PEP 750 introduced template strings, spelled with a t prefix. They look almost identical to f-strings but behave fundamentally differently: instead of producing a str, they produce a Template object that preserves the structure of the interpolation.

name = "Alice"
query = t"SELECT * FROM users WHERE name = {name}"

# query is a Template, not a str
# query.strings == ("SELECT * FROM users WHERE name = ", "")
# query.interpolations[0].value == "Alice"

This is not a feature for application code. It’s for library authors. The motivating case is SQL:

def safe_query(template: Template, conn) -> list:
    # Library can inspect interpolations and parameterize them properly
    sql = ""
    params = []
    for part in template.strings:
        sql += part
        if len(params) < len(template.interpolations):
            sql += "?"
            params.append(template.interpolations[len(params)].value)
    return conn.execute(sql, params).fetchall()

results = safe_query(t"SELECT * FROM users WHERE name = {name}", conn)

The database driver receives SELECT * FROM users WHERE name = ? plus ["Alice"] as a parameter, never concatenating user input into the SQL string. No wrapper function. No ORM required. Just the literal you wrote, structured for safe handling.

Beyond SQL, t-strings apply anywhere you want to intercept interpolation: HTML escaping, shell command construction, logging with deferred formatting. Web frameworks have already started shipping t-string aware APIs. Flask and FastAPI have both merged experimental branches.

f-strings remain the right choice for 99% of everyday formatting. t-strings are for the cases where f-strings are actually dangerous.

Deferred Annotation Evaluation by Default

This one has been a long time coming. from __future__ import annotations has been available since Python 3.7, making annotation evaluation lazy so you can write:

class Node:
    def next(self) -> Node:  # forward reference, works fine
        ...

Without the import, that would fail at class definition because Node isn’t defined yet.

PEP 649 makes deferred evaluation the default in 3.14, eliminating the need for the future import in new code. More importantly, it changes the semantics slightly from PEP 563 (which was the original 3.10 proposal that got delayed and revised repeatedly).

The key difference: annotations are not stored as strings. They’re stored as annotationdeferred objects that evaluate lazily on access. This means typing.get_type_hints() still works correctly, runtime type introspection works, and Pydantic’s magic continues functioning without hacks.

If you’ve been using from __future__ import annotations in every file, you can stop adding it to new files. Existing files work fine either way.

The one practical pain point: if you have code that relies on annotations being evaluated eagerly at class definition time (some metaclass patterns do this), you’ll need to audit those. The failure mode is a lazy evaluation that doesn’t error until the annotation is accessed, which can shift when an error surfaces in your test suite.

The Free-Threaded Build Is Production-Ready (For Some Workloads)

The GIL (Global Interpreter Lock) has been the defining constraint of CPython’s concurrency model for 30 years. In Python 3.13, an experimental free-threaded build appeared, labeled with t in version strings (e.g., python3.13t). Python 3.14 advances this significantly.

Three things changed in 3.14 for the free-threaded build:

Extension module compatibility improved. A big blocker in 3.13 was that popular C extensions (NumPy, Pydantic’s Rust core, etc.) needed explicit opt-in to declare themselves GIL-independent. In 3.14, more extensions work out of the box, and NumPy 2.2+ is fully compatible.

The Mimalloc allocator is the default for the free-threaded build. Python’s memory allocator has always been thread-safe at a coarse level. With GIL removal, fine-grained allocator thread safety becomes critical. Mimalloc is significantly faster than the previous default for multi-threaded allocation patterns.

The performance overhead dropped. In 3.13t, the single-threaded overhead of running the free-threaded build over the standard build was around 15-20% on most benchmarks. In 3.14t, that’s down to 3-8% depending on the workload.

What this means in practice: if you run CPU-bound Python on multi-core machines, the free-threaded build is worth testing today. Data processing pipelines, image manipulation, and numerical work all see real speedups with threading.Thread when the GIL isn’t serializing them.

What it doesn’t mean: async Python (asyncio, trio) doesn’t benefit from the GIL removal. Async has always been about I/O concurrency, not CPU parallelism. You don’t need the free-threaded build for web servers.

import threading
import time

def cpu_work(n: int) -> int:
    total = 0
    for i in range(n):
        total += i * i
    return total

# With standard Python: threads don't parallelize CPU work
# With Python 3.14t: these actually run in parallel
threads = [threading.Thread(target=cpu_work, args=(10_000_000,)) for _ in range(4)]
start = time.perf_counter()
for t in threads:
    t.start()
for t in threads:
    t.join()
print(f"Wall time: {time.perf_counter() - start:.2f}s")

On a 4-core machine, the free-threaded build completes this roughly 3.5x faster than the standard build. That ratio improves as the work gets more CPU-intensive.

locals() Finally Has Predictable Semantics

PEP 667 is the kind of fix that makes you realize something was quietly broken all along.

locals() has always returned a snapshot of the local namespace. If you modified the returned dict, nothing happened to the actual locals. The behavior was defined as implementation-specific, which meant CPython did one thing and PyPy did another, and type checkers had to pick one and hope.

In 3.14, locals() returns a real mapping that reflects the current local state and can be observed to update when locals change. Debuggers and profilers that relied on frame manipulation now have a stable API. The change is mostly invisible to application code but fixes a class of subtle bugs in tools that inspect Python frames.

What Hasn’t Changed: The Parts Worth Keeping Stable

Python’s packaging story is still evolving but not from the language itself. pyproject.toml with uv or pip + hatchling is the current clean path; nothing in 3.14 disrupts that.

Async/await syntax is unchanged. If you’re on asyncio, everything works as before.

The match statement from 3.10 got minor refinements but no breaking changes. Existing patterns continue working.

Upgrading: The Practical Checklist

Before upgrading production to 3.14:

1. Run python -W error::DeprecationWarning against your test suite on 3.12 or 3.13 first. Many things deprecated in 3.10-3.12 are removed in 3.14. Better to catch them on a version where they still run.

2. Check your C extensions. If any dependency ships compiled wheels, make sure 3.14 wheels exist. PyPI’s wheel availability has improved but isn’t universal for niche packages.

3. Test typing.get_type_hints() on your models if you use Pydantic, attrs, or similar. Deferred annotations change when evaluation happens. Most modern versions handle it correctly, but pinned old versions may not.

4. If you want the free-threaded build, install python3.14t alongside your regular 3.14. Don’t default-switch your whole stack to it. Run benchmarks on your specific workload first.

The upgrade path from 3.11+ is clean. If you’re on 3.9 or earlier, there are more intermediate breaking changes to work through, and you’ll want to step through 3.10 and 3.12 rather than jumping directly.

Python 3.14 isn’t a revolution. It’s the accumulated result of fixing things that have been awkward for years: forward references, template-safe interpolation, real parallelism for CPU work. Those fixes compound over time, and the codebase you’re writing today will run on 3.14 for several years. Getting on the current release before 3.15 ships in October is the right call.