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.
