[burky]

f-strings won’t sanitize the value, so it’s not safe. The article talks about this.

[Tenoke]

The article talked about it but the example here just assumes they'll be there.

[sanderjd]

What do you mean by "they"? You mean the template interpolation functions?

Yes, the idea is that by having this in the language, library authors will write these implementations for use cases where they are appropriate.

[Tenoke]

The sanitization. Just using a t-string in your old db.execute doesn't imply anything safer is going on than before.

[nemetroid]

Your "old" db.execute (which presumably accepts a regular old string) would not accept a t-string, because it's not a string. In the original example, it's a new db.execute.

[masklinn]

Using a t-string in a db.execute which is not compatible with t-strings will result in an error.

Using a t-string in a db-execute which is, should be as safe as using external parameters. And using a non-t-string in that context should (eventually) be rejected.

[Tenoke]

Again, just because a function accepts a t string it doesn't mean there's sanitization going on by default.

[tikhonj]

Yes, but if a function accepts a template (which is a different type of object from a string!), either it is doing sanitization, or it explicitly implemented template support without doing sanitization—hard to do by accident!

The key point here is that a "t-string" isn't a string at all, it's a new kind of literal that's reusing string syntax to create Template objects. That's what makes this new feature fundamentally different from f-strings. Since it's a new type of object, libraries that accept strings will either have to handle it explicitly or raise a TypeError at runtime.

[masklinn]

Because t-strings don't create strings, so if the library doesn't support t-strings the call can just error.