←back to thread

Python’s new t-strings

(davepeck.org)
620 points tambourine_man | 5 comments | 21 Apr 25 04:31 UTC | HN request time: 0.855s | source
Show context
Smithalicious ◴[21 Apr 25 11:38 UTC] No.43750764[source]▶
I really was on the side of being generally willing to accept new python features, but this is getting ridiculous. What an utterly pointless thing to bloat the language with. At this point my moving to clojure as my first line language of choice is only accelerating.

This is of the category "things I wouldn't want to use even for the specific hyper niche things they're intended for". What even does a "t-string" represent? Because it's clearly not a string of any kind, it's a weird kind of function call notation. The programmer sees something that looks like string formatting, but the program executes some arbitrary procedure that might not return a string whatsoever.

replies(2): >>43751148 #>>43751503 #
1. nhumrich ◴[21 Apr 25 12:22 UTC] No.43751148[source]▶
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.
replies(3): >>43754773 #>>43755585 #>>43755797 #
2. pauleveritt ◴[21 Apr 25 18:12 UTC] No.43754773[source]▶
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.
3. Smithalicious ◴[21 Apr 25 19:35 UTC] No.43755585[source]▶
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.

replies(1): >>43775276 #
4. stefan_ ◴[21 Apr 25 19:56 UTC] No.43755797[source]▶
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.

5. calfuris ◴[23 Apr 25 18:36 UTC] No.43775276[source]▶
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.