What do Python 3.14 t-strings change about interpolating untrusted values?

### What a t-string evaluates to Python 3.14 added **template strings** (PEP 750). Written with a `t` prefix, `t"Hello {name}"` looks like an f-string but does not produce a `str`. It evaluates to a `string.templatelib.Template`: an object that keeps the literal chunks and the interpolated values apart. ```python from string.templatelib import Template, Interpolation name = "ada" tmpl = t"Hello {name!r:>8}" tmpl.strings # ('Hello ', '') tmpl.values # ('ada',) tmpl.interpolations # (Interpolation('ada', 'name', 'r', '>8'),) ``` Iterating a `Template` yields those parts in order — `str` chunks and `Interpolation` objects alternating. Each `Interpolation` carries the evaluated `value`, the source text of the expression that produced it, the conversion (`!r`, `!s`, `!a`) and the format spec. Templates concatenate with `+`, and an f-string-style spec is preserved rather than applied. ### Why the separation is the security property The bug class t-strings attack is not template injection; it is **losing track of provenance**. By the time an f-string has produced a `str`, the literal parts and the interpolated user data are indistinguishable — a sink that receives it (HTML, a shell command line, a query string, a log record) cannot tell which characters the developer wrote and which the attacker did, so it cannot escape only the second kind. Escaping therefore has to happen at every call site, by hand, and the one site that forgets is the vulnerability. A `Template` postpones the join. The renderer sees the seam, so it can escape values and leave literals alone — one policy, in one place, applied to every interpolation by construction: ```python import html from string.templatelib import Interpolation, Template def render(template: Template) -> str: parts = [] for part in template: parts.append(html.escape(str(part.value)) if isinstance(part, Interpolation) else part) return "".join(parts) comment = "<script>alert(1)</script>" render(t"<p>{comment}</p>") # '<p>&lt;script&gt;alert(1)&lt;/script&gt;</p>' ``` ### Nothing renders by default, on purpose There is no automatic conversion to `str`. Calling `str()` on a `Template` gives a debug representation — `Template(strings=..., interpolations=...)` — not interpolated text, so a `Template` handed to a function that expected a finished string produces visible nonsense or a type error rather than a silently unescaped payload. The design deliberately declines to pick a rendering, because the correct one depends on the destination: HTML escaping, shell quoting and query-parameter binding are different answers to the same question, and a library that accepts a `Template` gets to give its own. ### What t-strings do *not* do They are compile-time syntax, exactly like f-strings. The literal parts come from your source file, so a template that arrives at runtime — in a request body, a settings row, a translation table — is still an ordinary `str`, and rendering it still means `str.format` and still means the attribute-walk problem. A candidate who offers t-strings as the fix for attacker-supplied templates has confused two different bugs. They also do not escape anything by themselves: a `Template` is inert until some renderer walks it, and a renderer that joins the parts without escaping is exactly as unsafe as the f-string it replaced. The value is that the escaping decision now has a single, checkable home. ### Where it matters in practice The realistic payoff is in library APIs. A function can declare that it takes a `Template` rather than a `str`, and thereby refuse pre-joined input at the type level: the caller cannot smuggle in a string built by concatenation, because the parameter simply is not a `str`. That is the same shape as a database driver refusing a fully-formed statement in favour of a statement plus parameters, and it is a considerably stronger contract than a docstring asking callers to escape first. Ecosystem support is early — 3.14 is the first release with the feature — so treat it as a direction of travel for new interfaces rather than a migration to run across an existing codebase. ### Version context `string.templatelib` and the `t` prefix are **new in Python 3.14**. On 3.13 and earlier they do not exist: the module import fails and the literal is a syntax error, so code using them cannot be backported by a shim. Asserting a t-string in a codebase that still supports 3.13 is a version-floor decision, not a style choice.