Python 3.14: Template Strings, Deferred Annotations and More

Description

Python 3.14 (October 2025) is the newest release in this course. Its two headline features change how strings and annotations are evaluated: template strings (t"..."), which keep values apart from the text around them so they can be escaped safely, and deferred annotations, which are evaluated only when something asks for them. It also brings a handful of smaller changes you'll meet in code review.

Here's the kind of bug t-strings exist for. A team builds SQL with f-strings and relies on code review to catch injection:

cursor.execute(f"SELECT * FROM users WHERE name = '{name}'")

With name = "Ada'); DROP TABLE users;--" the query is whatever the attacker wrote. An f-string produces a finished str - by the time execute sees it, the value and the SQL are indistinguishable. Python 3.14's template strings keep them apart:

query = t"SELECT * FROM users WHERE name = {name}"   # a Template, not a str

A library can turn that into 'SELECT * FROM users WHERE name = %s' plus [name] - a parameterized query - from the same convenient syntax (a test's ten-line renderer did exactly that).

We'll go from simple to more technical:

1. Template strings: what a Template holds and why it isn't a str.
2. Deferred annotations: forward references without quotes, and how to read annotations safely.
3. Smaller changes: except A, B:, warnings for return in finally, zstd and uuid7.

Template strings (PEP 750)

from string.templatelib import Template, Interpolation

t = t"SELECT * FROM users WHERE name = '{name}'"
t.strings          # ("SELECT * FROM users WHERE name = '", "'")
t.interpolations   # (Interpolation(value="Ada'); DROP...", expression='name', ...),)

def to_sql(template: Template) -> tuple[str, list]:
    parts, params = [], []
    for item in template:                       # yields strings and Interpolations in order
        if isinstance(item, Interpolation):
            parts.append("%s"); params.append(item.value)
        else:
            parts.append(item)
    return "".join(parts), params

• A t-string evaluates its expressions immediately, like an f-string, but returns a Template: the literal parts and the values (with their expression text and any !r/:spec) are kept separately.
• It is not a str: "x" + t"y" raises TypeError, and str(t) doesn't render it - so a template can't silently become an unescaped string. Something must process it: an SQL driver, an HTML escaper, a structured logger that records the values as fields.
• The standard library provides the types; the renderers come from libraries. The point is that APIs can require a Template for anything security-sensitive.

Deferred annotations (PEP 649/749)

Until 3.14, annotations were evaluated when the def or class ran, so a forward reference needed quotes (customer: "Customer") or from __future__ import annotations. In 3.14 they're evaluated lazily:

class Order:
    customer: Customer        # Customer is defined later in the module - fine
    total: int

• The class is defined without error even though Customer doesn't exist yet. Reading Order.__annotations__ evaluates them then - and, if Customer is still undefined, raises NameError: name 'Customer' is not defined (as a test showed).
• annotationlib.get_annotations(obj, format=...) reads them safely: Format.VALUE (evaluate, may raise), Format.FORWARDREF (undefined names become ForwardRef('Customer')), Format.STRING ({'customer': 'Customer', 'total': 'int'}). Frameworks that read annotations (dataclasses, Pydantic, FastAPI) use these instead of __annotations__.
• Startup gets cheaper (annotations are never evaluated unless someone asks), and from __future__ import annotations is no longer needed for forward references.

Smaller changes in 3.14

• except A, B: without parentheses (PEP 758): except ValueError, TypeError: catches either, as except (ValueError, TypeError): always did. With as the parentheses are still required. (Before 3.14 the unparenthesized form was a SyntaxError.)
• Control flow in finally (PEP 765): return, break or continue inside a finally block now gives a SyntaxWarning - 'return' in a 'finally' block - because it silently discards any exception being propagated.
• compression.zstd: Zstandard compression in the standard library (with compression.gzip, .bz2, .lzma aliases in the new package).
• uuid.uuid7(): time-ordered UUIDs (version 7) that sort by creation time - good database keys, unlike random uuid4.
• From earlier skills: the free-threaded build is officially supported (PEP 779), concurrent.interpreters and InterpreterPoolExecutor (PEP 734), forkserver is Linux's default multiprocessing start method, and asyncio gained python -m asyncio ps PID to inspect a running program's tasks.

Which tool for which job?

Common mistakes

Check yourself

Try to answer before opening each one - recalling beats re-reading.

1. What's the difference between f"... {name}" and t"... {name}"?

2. On 3.14, a class annotates customer: Customer before Customer is defined. When, if ever, does that fail?

3. Why does 3.14 warn about return inside finally?

Key takeaways

• t-strings: templates, not strings - the basis for safe SQL, HTML and logging APIs.
• Annotations are lazy in 3.14: forward references just work; read them with annotationlib.
• except A, B: without parentheses; warnings for return in finally.
• zstd, uuid7, supported free-threading and subinterpreters round out the newest release.