←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: 0.414s | 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 #
tubthumper8 ◴[21 Apr 25 12:52 UTC] No.43751442[source]▶
Do the python type checkers / linters / whatever have the ability to warn or error on calling certain functions? That would be nice to eventually enforce migration over to the newer functions that only take a t-string template
replies(2): >>43751614 #>>43754874 #
1. mos_basik ◴[21 Apr 25 18:21 UTC] No.43754874[source]▶
Yeah. A while back I was poking through some unfamiliar code and noticed that my editor was rendering a use of `datetime.utcnow()` as struck through. When I hovered it with my mouse, I got a message that that function had been deprecated.

Turns out my editor (vscode) and typechecker (pyright) saw that `datetime.utcnow()` was marked as deprecated (I know one can use the `@deprecated` decorator from Python 3.13 or `__future__` to do this; I think it was done another way in this particular case) and therefore rendered it as struck through.

And it taught me A) that `utcnow()` is deprecated and B) how to mark bits of our internal codebase as deprecated and nudge our developers to use the new, better versions if possible.

replies(1): >>43771260 #
2. tubthumper8 ◴[23 Apr 25 12:21 UTC] No.43771260[source]▶
Can you do it for functions defined by other people, or only for functions that you defined?

I'm thinking in the general case, but motivated by this example of a 3rd party function that accepts a SQL query as a string, and we'd like everywhere in our codebase to stop using that and instead use the 3rd party function that accepts the query as a t-string