Python t-strings (PEP 750): A Tested, Practical Guide

The syntax is deliberately familiar. An f-string builds a string on the spot; a t-string of the identical shape returns a Template instead — a small object holding the pieces. The prefix is t; everything else ({expr}, !r conversions, :spec formats) is exactly what you already know from f-strings:

from string.templatelib import Template, Interpolation

name = "mithun"
role = "admin"
t = t"user {name} is {role}"

print(type(t).__name__)               # Template
print([type(p).__name__ for p in t])  # ['str', 'Interpolation', 'str', 'Interpolation']
print(t.strings)                      # ('user ', ' is ', '')
print(t.values)                       # ('mithun', 'admin')

Notice what you get back: .strings is the tuple of literal text chunks *between* the holes, .values is the tuple of interpolated results, and iterating the template yields those pieces in order — a plain str for each literal, an Interpolation object for each {...}. Nothing has been combined yet. That deferral is the entire feature.

Each hole becomes an Interpolation, and it carries everything the parser knew about that hole — not just the value, but the original expression text and any conversion or format spec you wrote:

qty = 5
t2 = t"total: {qty * 2!r:>6}"

interp = [p for p in t2 if isinstance(p, Interpolation)][0]
print(interp.value)        # 10
print(interp.expression)   # 'qty * 2'
print(interp.conversion)   # 'r'
print(interp.format_spec)  # '>6'

So t"total: {qty * 2!r:>6}" tells a processor: the value is 10, it came from the source expression qty * 2, apply repr (the !r), then format with >6. Your processor decides whether to honour those instructions — which is exactly what makes t-strings *programmable* where f-strings are fixed.

Here's the one gotcha everyone hits: a t-string does nothing on its own. PEP 750 defines only the literal; it deliberately ships *no* built-in renderer. To get a string back you write (or import) a template processor. This one reproduces ordinary f-string behaviour, so you can see all the moving parts in one place:

def render(template):
    out = []
    for part in template:
        if isinstance(part, str):
            out.append(part)
        else:                                  # an Interpolation
            v = part.value
            if part.conversion == "r":
                v = repr(v)
            out.append(format(v, part.format_spec))
    return "".join(out)

print(render(t"user {name} is {role}"))   # user mithun is admin
print(render(t"total: {qty * 2!r:>6}"))    # total:     10

This is why t-strings matter for anyone shipping real software. The classic f-string mistake is building a SQL query by interpolation — which drops user input straight into the query text:

user_input = "'; DROP TABLE users; --"

# f-string: the attack is already baked into the final string
q = f"SELECT * FROM users WHERE name = '{user_input}'"
print(q)
# SELECT * FROM users WHERE name = ''; DROP TABLE users; --'

# t-string: a processor turns each interpolation into a ? placeholder + param
def to_query(template):
    sql, params = "", []
    for part in template:
        if isinstance(part, str):
            sql += part
        else:
            sql += "?"
            params.append(part.value)
    return sql, params

sql, params = to_query(t"SELECT * FROM users WHERE name = {user_input}")
print(sql)     # SELECT * FROM users WHERE name = ?
print(params)  # ["'; DROP TABLE users; --"]

The f-string has already concatenated the attack into the query — there's nothing left to sanitise. The t-string version never combines them: the processor walks the template, replaces every interpolation with a ? placeholder, and collects the values into a separate params list — exactly the shape cursor.execute(sql, params) expects. Same convenient syntax, but parameterised and injection-safe by construction.

The identical pattern escapes HTML. The static markup you wrote in the template is trusted; the interpolated values get html.escaped:

import html
comment = "<script>alert(1)</script>"

def safe_html(template):
    out = []
    for part in template:
        if isinstance(part, str):
            out.append(part)                          # trusted static markup
        else:
            out.append(html.escape(str(part.value)))  # escape interpolated value
    return "".join(out)

print(safe_html(t"<p>{comment}</p>"))
# <p>&lt;script&gt;alert(1)&lt;/script&gt;</p>

The <script> tag the user submitted comes out inert — <script>... — while the surrounding <p> you wrote stays real markup. That separation between *your* template and *their* data is exactly what an f-string collapses, and what a t-string keeps apart.

t-strings are a Python 3.14 feature (shipped October 2025). They're *syntax*, so there's no __future__ import and no backport — on Python 3.13 and earlier the parser rejects the literal outright:

# Python 3.14+  ->  works
t = t"hello {name}"        # a Template object

# Python 3.13 and earlier  ->  rejected by the parser
t = t"hello {name}"
#     ^^^^^^^^^^^^^^
# SyntaxError: invalid syntax

If you need to confirm which interpreters accept a snippet, our online Python compiler defaults to Python 3.14 (so t-strings run) and lets you flip to 3.13 or 3.12 to watch the same code turn into a SyntaxError. And to see how a t-string actually compiles — it builds the Template at runtime — paste it into the bytecode disassembler.

Rule of thumb: reach for an f-string for everyday formatting — logs, messages, quick output. It's simpler, and t-strings aren't trying to replace it. Reach for a t-string whenever interpolated values need to be *treated* before they're combined: SQL parameters, HTML or shell escaping, structured logging, or building a small domain-specific language.