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.

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.

I'm not the OP but I'm guessing with OP moving to Clojure that the bloat is basically any special syntax or special language feature that basically boils down to a function call or a let statement. A lot of functional programming languages have minimalistic expression syntax and they are just as expressive as OP needs them to be.

It's a pattern moreso than this specific feature. There's an important qualitative distinction for me between something that's on the level of a library (even if it's the stdlib) on the one hand and first class features (ie things that require parser level support) on the other.

Python has historically been very conservative about this but in recent years has had one controversial language extension after another, while parts of the language that actually need love are left to languish IMO.

I wanna be very clear that this is me changing my mind -- I was (still am) very on board with the highly controversial assignment expressions ("walrus operator") for instance.

I don't have much faith about what the Python language will look like if you project the current rate of changes forward 10, 15, 20 years. It really doesn't help that I consider this new thing an active antifeature.