←back to thread

Python’s new t-strings

(davepeck.org)
620 points tambourine_man | 1 comments | 21 Apr 25 04:31 UTC | HN request time: 0.214s | 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 #
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 #
1. 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.