←back to thread

Python’s new t-strings

(davepeck.org)
620 points tambourine_man | 2 comments | 21 Apr 25 04:31 UTC | HN request time: 0s | source
Show context
TekMol ◴[21 Apr 25 08:37 UTC] No.43749608[source]▶
Will this allow neat SQL syntax like the following?

    city = 'London'
    min_age = 21
    # Find all users in London who are 21 or older:
    users = db.get(t'
        SELECT * FROM users
        WHERE city={city} AND age>{min_age}
    ')
If the db.get() function accepts a template, it should, right?

This would be the nicest way to use SQL I have seen yet.

replies(8): >>43749674 #>>43749734 #>>43749906 #>>43749926 #>>43749979 #>>43750037 #>>43751845 #>>43756963 #
jbaiter ◴[21 Apr 25 08:47 UTC] No.43749674[source]▶
Thanks, I hate it. While it's nice syntactic sugar, the difference between an SQL injection vulnerability and a properly parametrized query is now a single letter that's easily missed
replies(5): >>43749680 #>>43749683 #>>43749690 #>>43749804 #>>43750217 #
JimDabell ◴[21 Apr 25 09:07 UTC] No.43749804[source]▶
The t-string produces a Template object without a __str__() method. You can’t mistakenly use an f-string in its place. Either the code expects a string, in which case passing it a Template would blow it up, or the code expects a Template, in which case passing it a string would blow it up.
replies(5): >>43749994 #>>43750148 #>>43750347 #>>43751082 #>>43752420 #
politelemon ◴[21 Apr 25 09:37 UTC] No.43749994[source]▶
And I'm guessing lots of code will expect strings to maintain backward compatibility.
replies(2): >>43750449 #>>43751326 #
Mawr ◴[21 Apr 25 10:55 UTC] No.43750449[source]▶
I'm guessing no existing functions will be extended to allow t-strings for this very reason. Instead, new functions that only accept t-strings will be created.
replies(2): >>43750913 #>>43751442 #
1. xorcist ◴[21 Apr 25 11:58 UTC] No.43750913{3}[source]▶
There's an obvious risk here, same as with strcpy (no, strncpy.. no, strlcpy... no, strcpy_s) that documentation tends to outlive code, and people keep pasting from tutorails and older code so much that the newer alternatives have a hard time cutting through the noise.

I would argue that as bad as some w3schools tutorials were, and copying from bad Stackoverflow answers, going back to MSA and the free cgi archives of the 90s, the tendency of code snippets to live on forever will only be excarbated by AI-style coding agents.

On the other hand, deprecating existing methods is what languages do to die. And for good reason. I don't think there's an easy answer here. But language is also culture, and shared beliefs about code quality can be a middle route between respecting legacy and building new. If static checking is as easy as a directive such as "use strict" and the idea that checking is good spreads, then consesus can slowly evolve while working code keeps working.

replies(1): >>43751341 #
2. sanderjd ◴[21 Apr 25 12:41 UTC] No.43751341[source]▶
It's pretty common for Python libraries to deprecate and remove functionality. It makes people mad, but it's a good thing, for this reason.