What does a Python 3.14 t-string actually defer, and what does an API typed to accept Template gain over str?

"Deferred" is the word that causes the most confusion about t-strings, so start by pinning it down. In **Python 3.14** (PEP 750), `t"archiving {next_id()}"` calls `next_id()` immediately, at the moment the literal is evaluated, exactly as an f-string would. Nothing about the expressions is lazy. What is deferred is the **joining** -- the step that would flatten the literal chunks and the values into one `str`. That distinction has a consequence people miss: a t-string is not a way to build a template once and substitute different values later. It captures results, not thunks. If you want re-substitution you want a different tool. ### What survives the deferral Because the join has not happened, a `string.templatelib.Template` still knows which characters came from the source file and which came from a value. `.strings` holds the literal chunks; `.interpolations` holds one `Interpolation` per `{...}`, each carrying `.value`, `.expression`, `.conversion` and `.format_spec`. That boundary is exactly the information an f-string destroys, and destroys **irreversibly**: once you hold a flat `str`, no amount of inspection tells you which of its characters the programmer typed. Re-parsing is guesswork, and guesswork is where the bugs are. ### Why the parameter type is the real change Consider a transcript archiver that shells out to compress finished chat logs and renders HTML previews of them, running a 1,200-request-per-minute peak at end of day. Version one publishes helper functions -- `shlex.quote` for command words, `html.escape` for preview text -- and documents that callers must use them. That design fails in the ordinary way: the helper is a convention, and conventions are enforced by memory. One call site out of two hundred forgets, and nothing detects it, because a forgotten escape and a correct one both produce a `str`. Version two types the entry point as `def run(command: Template) -> None` and does the quoting itself. Now the boundary is enforced by the interpreter. A caller who passes an f-string gets a `TypeError` at the call, not a wrong result at 2 a.m. -- `Template` is not a `str` subclass and has no `__str__` that interpolates, so there is no silent degradation path. The escaping logic lives in one reviewed function instead of at every call site, and the call sites become uniformly readable: `run(t"gzip -k {path}")` says what it means. That is the whole strategic argument. t-strings do not make values safe; they make it possible to write an API that **cannot be called wrongly**, which is a categorically different property from an API that is easy to call rightly. ### The failure modes that remain * **A bad renderer.** A t-string escapes nothing on its own. A renderer that calls `str()` on the whole template, or that applies `html.escape` to a value destined for a shell word, is exactly as broken as the f-string it replaced. The gain is that the mistake now has one location. * **A union parameter.** `def run(command: str | Template)` reopens everything. The moment a caller may pass a `str`, the boundary is already gone for that call, and no runtime check restores it. If you must migrate incrementally, keep two separately named entry points -- the `str` one explicitly marked legacy -- so the unconverted call sites are greppable and a static checker can flag them, rather than one polymorphic parameter that hides them. * **Rendered text fed back in.** Interpolating an already-rendered string into a template gives the renderer no way to know that its contents were once structured. Templates compose from templates and values, not from output. ### The cost side of the decision The floor is 3.14 for any module containing a t-string, and because `t"..."` is a `SyntaxError` on 3.13 and earlier, the module fails at **import**, not at call time. You cannot guard it with a version check in the same file. In practice that means the choice is made per service, not per call site: either the runtime is 3.14+ and you can convert freely, or template-using code has to be isolated behind a separate importable module, which usually costs more attention than the conversion saves. There is also an ecosystem question. The value of a `Template`-typed API is highest at boundaries you own. Where you are handing text to a third-party library that only accepts `str`, you still render before the call, and the guarantee ends there -- so the honest scope of the technique is your own internal builders first. ### How to argue it in an interview State the mechanics first: eager expressions, deferred join, structure preserved. Then make the design point: the win is not escaping, it is that the type of the parameter now carries a property the callee can rely on. Then price it: a 3.14 floor, a renderer per target grammar that has to be written and tested, and a migration that must not go through a union type. That sequence -- mechanism, design consequence, cost -- is what separates someone who read the release notes from someone who has weighed the change.