yes, it does actually need syntax support. In order for it to work, you need to preserve which parts of the string are static (hard coded) and which parts are dynamic (likely user input). Which you can only do at a syntax level. You could potentially do it by hand, using placeholders, like with `%`, but as we now live in f-string world, we have something better. The syntax highlighting and ergonomics of f-strings are so good, devs prefer it in most cases. The idea is to make the most ergonomic thing, also the safest thing. By decreasing ergonomics, you reduce the adoption of safer symantics.
That's why I specified the context argument. Something like Template("{name} {address}", dict(name = ..., address = ...)) would be exactly equivalent to t"{name} {address}" assuming those variables are fetched from the local scope.
Yes, which is essentially how SQLalchemy works today. You can still put strings in the context though, so for more complex things, it's turtles all the way down. Also, as f-srrings are more ergonomic, people now reach for them, even when they shouldn't
So now you are repeating the name of each interpolated value three times (once in the template string, once for the key in the dict, once for the actual value).
Yes, you can do that, but a t-string is much more ergonomic, and IMO, more readable .
Yes, of course. Any function with syntactic support will be more "ergonomic" than one without. But t-strings are for a relatively niche use case and can't even fully replace f-strings since they aren't actually strings. Even for input sanitizing they seem insufficient since you cant use them to create pre-compiled statements/templates.
