←back to thread

Python’s new t-strings

(davepeck.org)
620 points tambourine_man | 4 comments | 21 Apr 25 04:31 UTC | HN request time: 0s | source
Show context
serbuvlad ◴[21 Apr 25 09:51 UTC] No.43750075[source]▶
All things considered, this is pretty cool. Basically, this replaces

    db.execute("QUERY WHERE name = ?", (name,))
with

    db.execute(t"QUERY WHERE name = {name}")
Does the benefit from this syntactic sugar outweigh the added complexity of a new language feature? I think it does in this case for two reasons:

1. Allowing library developers to do whatever they want with {} expansions is a good thing, and will probably spawn some good uses.

2. Generalizing template syntax across a language, so that all libraries solve this problem in the same way, is probably a good thing.

replies(12): >>43750226 #>>43750250 #>>43750260 #>>43750279 #>>43750513 #>>43750750 #>>43752117 #>>43752173 #>>43752293 #>>43754738 #>>43756560 #>>43763190 #
benwilber0 ◴[21 Apr 25 14:06 UTC] No.43752173[source]▶
Aren't there other benefits to server-side parameter binding besides just SQL-injection safety? For instance, using PG's extended protocol (binary) instead of just raw SQL strings. Caching parameterized prepared statements, etc.

Also:

    db.execute(t"QUERY WHERE name = {name}")
Is dangerously close to:

    db.execute(f"QUERY WHERE name = {name}")
A single character difference and now you've just made yourself trivially injectible.

I don't think this new format specifier is in any way applicable to SQL queries.

replies(12): >>43752236 #>>43752283 #>>43752331 #>>43752336 #>>43752358 #>>43752859 #>>43753280 #>>43753699 #>>43754372 #>>43754646 #>>43755330 #>>43756720 #
MR4D ◴[21 Apr 25 14:21 UTC] No.43752336[source]▶
Dang! Thanks for pointing this out.

I had to look SEVERAL times at your comment before I noticed one is an F and the other is a T.

This won’t end well. Although I like it conceptually, this few pixel difference in a letter is going to cause major problems down the road.

replies(1): >>43752552 #
pphysch ◴[21 Apr 25 14:42 UTC] No.43752552[source]▶
How? tstrings and fstrings are literals for completely different types.

CS has survived for decades with 1 and 1.0 being completely different types.

replies(3): >>43753130 #>>43753177 #>>43754544 #
MR4D ◴[21 Apr 25 17:50 UTC] No.43754544[source]▶
Reread my comment. It’s about noticing you have an “f” or a “t” and both are very similar characters.
replies(1): >>43754644 #
rocha ◴[21 Apr 25 18:00 UTC] No.43754644[source]▶
Yes, but you will get an error since string and templates are different types and have different interfaces.
replies(1): >>43755714 #
Izkata ◴[21 Apr 25 19:48 UTC] No.43755714[source]▶
Click "parent" a few times and look at the code example that started this thread. It's using the same function in a way that can't distinguish whether the user intentionally used a string (including an f-string) and a t-string.
replies(1): >>43756771 #
zahlman ◴[21 Apr 25 21:36 UTC] No.43756771{3}[source]▶
Yes, and the parent is misguided. As was pointed out in multiple replies, the library can distinguish whether an ordinary string or a t-string is passed because the t-string is not a string instance, but instead creates a separate library type. A user who mistakenly uses an f prefix instead of a t prefix will, with a properly designed library, encounter a `TypeError` at runtime (or a warning earlier, given type annotations and a checker), not SQL injection.
replies(1): >>43758123 #
1. Izkata ◴[22 Apr 25 00:57 UTC] No.43758123{4}[source]▶
In this particular instance it can't, because there are 3 ways in question here, and it can't distinguish between correct intentional usage and accidental usage of an f-string instead of a t-string:

  db.execute("SELECT foo FROM bar;")
  db.execute(f"SELECT foo FROM bar WHERE id = {foo_id};")
  db.execute(t"SELECT foo FROM bar WHERE id = {foo_id};")
The first and second look identical to execute() because all it sees is a string. But the second one is wrong, a hard-to-see typo of the third.

If f-strings didn't exist there'd be no issue because it could distinguish by type as you say. But we have an incorrect SQL-injection-prone usage here that can't be distinguished by type from the correct plain string usage.

replies(1): >>43764565 #
2. Timon3 ◴[22 Apr 25 17:42 UTC] No.43764565[source]▶
There is no reason to support the first or second usage. It's totally fine to always require a t-string:

    db.execute(t"SELECT foo FROM bar;")
See? No reason to accept strings, it's absolutely fine to always error if a string is passed.
replies(1): >>43765327 #
3. Izkata ◴[22 Apr 25 19:16 UTC] No.43765327[source]▶
My (and their) point is that's the already existing API. You're proposing a big breaking change, with how many frameworks and tutorials are built on top of that.
replies(1): >>43765451 #
4. Timon3 ◴[22 Apr 25 19:30 UTC] No.43765451{3}[source]▶
It's not like this is the first time APIs have been improved. There are many tools (e.g. deprecation warnings & hints in editors, linter rules) that can help bridge the gap - even if t-strings are only used for new or refactored code, it's still a big improvement!

There's also simply no hard requirement to overload an `execute` function. We have options beyond "no templates at all" and "execute takes templates and strings", for example by introducing a separate function. Why does perfect have to be the enemy of good here?