It’s injection safe and compostable, and the resulting object retains the original values you interpolate in. This makes it useful for building SQL queries with prepared arguments for example.
It’s on a meta level: instead of formatting the string, it returns an object that contains both the format string and its argument. Library author can then implement whatever format function they want, for example one that escapes the interpolated strings.
f"foo is {foo} and {bar=}"
"foo is {} and bar={}".format(foo, bar)
are equivalent.
t-strings are actually not strings, but Template objects, giving access to both the templating string and the parameters for processing. Sibling comments describe it as a custom .format implementation in that sense - it's f-string-like sugar where you're also allowed to take control of the .format function that it's sugar for.
f-strings are actually translated into formatting and concatenation of the pieces at a bytecode level; they don't call `.format` under the hood and thus aren't what I'd call "syntactic sugar" in the traditional sense. But yes, the equivalence holds.
t-strings, of course, (will) translate at the bytecode level into instantiation of the Template object (and whatever code is needed to compute the Interpolation values in-place).
