How do you walk a string.templatelib.Template to render it with per-value escaping?

Rendering is where t-strings earn their keep, because a `string.templatelib.Template` object -- new in **Python 3.14** with PEP 750 -- deliberately has no rendered form of its own. Somebody has to write the function that turns one into a `str`, and that function is where every escaping decision lives. ### The shape of the object A `Template` stores the literal text and the substituted values apart: * `.strings` is a tuple of the literal chunks typed in the source. * `.interpolations` is a tuple of `string.templatelib.Interpolation` objects, one per `{...}`. `len(.strings)` is always `len(.interpolations) + 1`, with empty strings padding the ends. `t"{user}"` therefore has `.strings == ("", "")`, and `t"id={user}"` has `("id=", "")`. Relying on that invariant is safe; assuming the two tuples are the same length is a bug. Each `Interpolation` exposes `.value` (the evaluated result), `.expression` (the source text of the expression), `.conversion` (`"r"`, `"s"`, `"a"` or `None`) and `.format_spec` (the text after the colon, or an empty string). ### Two ways to walk it You can zip the two tuples yourself, alternating a chunk and an interpolation, but the ergonomic form is to iterate the template directly. `Template` implements `__iter__`, and iteration yields the literal chunks and the `Interpolation` objects interleaved in source order, skipping the empty chunks. A renderer collapses to a single loop with one `isinstance` test: ```python import html from string.templatelib import Interpolation, Template def render(template: Template) -> str: out = [] for part in template: if isinstance(part, Interpolation): out.append(html.escape(format(part.value, part.format_spec))) else: out.append(part) return "".join(out) ``` ### The literal chunks are never escaped This is the rule people get backwards. The chunks in `.strings` came from the programmer's own source file; they are the markup, the command skeleton, the query shape. Escaping them would corrupt the output -- an HTML renderer that escapes its own `<p>` tags produces visible entity text instead of a paragraph. Only the interpolated values are escaped, because only they came from outside. ### Conversion and format spec are data, not behaviour A t-string parses `!r` and `:.3f` exactly as an f-string does, but it does not apply them. They arrive as `.conversion` and `.format_spec` for the renderer to honour, and a renderer that ignores them silently changes what the source asked for. Consider an archiver that logs `t"archived {count} transcripts in {elapsed:.3f}s"`. A renderer that skips `format_spec` and calls `str()` on the value emits the full binary-float expansion instead of three decimals, and totals assembled from those log lines drift away from the ones the source intended. Honouring the spec costs one call. Order matters: apply the conversion first, then the format spec, then escape. `format(part.value, part.format_spec)` produces the display text; escaping *that* text is what makes it safe for the target syntax. Escape first and the formatter is free to mangle your work -- an alignment or truncation spec can slice an escape sequence in half, and a numeric spec can discard quoting you added. ### One renderer per target syntax There is no universal escaper, and a renderer that tries to be one is worse than no renderer at all. HTML wants entity encoding via `html.escape`. A shell word wants `shlex.quote`, which wraps the value in single quotes and neutralises everything inside. A database driver wants parameter binding, not text substitution at all -- in that case the "renderer" produces a query with placeholders plus a separate tuple of values, and the `Template` is a convenient carrier for both. So the signature you write is `render_html(t: Template) -> str`, `render_shell(t: Template) -> str`, and so on. Each knows exactly one grammar. That is the payoff of the design: the escaping logic exists once, in a function that can be reviewed and tested on its own, instead of being re-derived at every call site. ### Testing a renderer Because the input is a structured object, renderers are unusually easy to test. Build a template with a hostile value, call the renderer, and assert on the output string. Assert too that the literal chunks survived unescaped, which catches the classic over-escaping regression. And assert that a value carrying a format spec comes out formatted, which catches the silent drift described above. ### What the renderer cannot do It cannot recover anything the template did not keep. The values were evaluated eagerly when the literal was evaluated, so a renderer sees results, not expressions to re-run -- `.expression` is source text for diagnostics, not something to evaluate. And it cannot fix a template that was built by concatenating an already-rendered string: once text is flat, the boundary is gone.