Avoid SQL Injection & Logging Overhead with t-Strings

Key Takeaways

two problems that fstrings don't solve which will kind of give you the context as to why this stuff is being done. The logging module still uses the old C style string templates where you've got that whole percent s as a placeholder thing going on. Not all logging calls actually log something. So if you're using the debug call but your level is set to error, then you don't want to spend any time doing calculations on formatting strings. You want to return as quickly as possible and do nothing. If you're using an F string with a login call, the string will get built before the call, meaning you're spending time on it, even if no log message is going to be output. The second problem is one that's also been around for a long time, SQL injection. When you write code to a database API, you are sometimes allowed to write SQL as a string. A nefarious actor might pass in something that also modifies your SQL. This is called an injection, and it's a big problem. Uh the famous little Bobby Tables cartoon is about exactly that. Python is doing the work that takes the fstring template and translating it into the resulting string. You as the programmer don't have any way of stepping into this. So a T-string looks very much like an Fstring, but it begins with the letter T instead, hence the name. But instead of returning a string, it returns a template object. This template object intentionally has no dunder string method. So you can't just cast it to a string. That's exactly what we're trying to avoid. Essentially, what's happening here is a hook into the fstring parser. A processed T-string template object contains the pieces that would have made up the equivalent fing. By doing this, it gives you the ability to deal with each piece separately. For logging, that would mean not invoking all the two string methods on the component arguments. And for something like SQL, it could mean escaping the content in order to avoid that injection