For me, this is the best feature to land in python for 6 years. JS has had this and it allows my code to be completely safe from SQL injection, which is an absolutely incredible feature, given SQL injection has been the #1 vulnerability for a long time.
Thanks Nick for this response and all the time you've spent explaining. It's funny, I looked back at the comments on f-strings before they landed. They also got similar complaints about bloat. And yet, my uneducated guess: very popular.
But this doesn't prevent SQL injection, does it? It adds a grammar feature that you can then use to build SQL injection prevention following a novel idiom. Someone still needs to write the actual SQL building logic somewhere!
I don't think this is the right idiom for doing this. Frankly I don't think SQL query generation should look like string templating at all!
The sell seems to be "now you can write code that looks like an SQL injection vulnerability, without it actually being vulnerable!". I'd rather write code that isn't a vulnerability, and doesn't look like one, and doesn't have to bend the language grammar either.
I'd rephrase the sell as "now people who are used to doing the wrong thing and risking vulnerabilities can do the right thing without any extra effort," with a footnote about the difference in types allowing libraries to force the change.
What? Maybe in 2005. This is just strictly worse than parameterized because now you are also wasting time "escaping" strings which perpetuates the whole mixing data & query thing nobody even wants anymore.
It's like even the one case identified nobody has even thought all the way through. Now your SQL library only accepts t-strings, I get an obscure error passing in a simple static query. Ah yes, put the useless t on it. That sorted, now the SQL library escapes all the parameters it wasn't previously doing, to then hand the final unique query to the actual underlying SQL library which would much rather have the parameterized one so it can cache parsing. Jesus.
