←back to thread

Python’s new t-strings

(davepeck.org)
620 points tambourine_man | 9 comments | 21 Apr 25 04:31 UTC | HN request time: 0.001s | source | bottom
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 #
1. 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 #
2. 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 #
3. xorcist ◴[21 Apr 25 11:58 UTC] No.43750913[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 #
4. sanderjd ◴[21 Apr 25 12:40 UTC] No.43751326[source]▶
I think it's way more likely that existing libraries will introduce new methods that use t-strings and are type safe, rather than entirely defeat the purpose of having a t-string API.
5. sanderjd ◴[21 Apr 25 12:41 UTC] No.43751341{3}[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.
6. 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 #
7. mb5 ◴[21 Apr 25 13:09 UTC] No.43751614{3}[source]▶
They sure do, e.g. https://docs.astral.sh/ruff/rules/pandas-use-of-dot-is-null/
8. mos_basik ◴[21 Apr 25 18:21 UTC] No.43754874{3}[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 #
9. tubthumper8 ◴[23 Apr 25 12:21 UTC] No.43771260{4}[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