[mikeholler]

A potential concern is how close this looks to the pattern they're trying to override.

    db.execute(f"QUERY WHERE name = {name}")

versus

    db.execute(t"QUERY WHERE name = {name}")

[notatoad]

The key point is that t-strings are not strings. Db.execute(t”…”) would throw an exception, because t”…” is not a string and cannot be interpreted as one.

In order for a library to accept t-strings, they need to make a new function. Or else change the behavior and method signature of an old function, which I guess they could do but any sanely designed library doesn’t do.

Handling t-strings will require new functions to be added to libraries.

[gls2ro]

yes but the bug is writing f instead of t and I assume f will just work.

To clarify even more:

The problem is not writing by mistake t instead of f => this is what we want and then for this we implement a new function

The problem is writing f instead of t => and this will silently work I assume (not a Python dev just trying to understand the language design)

[masklinn]

> The problem is writing f instead of t => and this will silently work I assume (not a Python dev just trying to understand the language design)

In the fullness of time it has no reason to. Even in the worst case scenario where you have to compose the query dynamically in a way t-strings can’t support, you can just instantiate a Template object explicitely.

[notatoad]

>yes but the bug is writing f instead of t and I assume f will just work

but it will not. f-strings and t-strings are not compatible types, they will not "just work". not unless somebody changes a library to make it just work. as long as nobody does that, it's not an issue.

[fzzzy]

But won't the f string version fail loudly because there's no name parameter?

[benwilber0]

the {name} parameter is in the locals() dict like it always is

[fzzzy]

Good point. Perhaps the database api could refuse strings and require Templates.

[bshacklett]

That’s a big breaking change around a brand new feature. I’m sure it could be done well, but it gives me the shivers.

[dragonwriter]

You add a new API that takes templates only leaving the existing API in place. You (some releases later) deprecate the string API. You (some releases later, with clear advance warning of when it is coming) actually remove the deprecated API. "It's a big breaking change around a brand new feature", yeah, so you don't break anything around a brand new feature, it's not like this kind of transition is a new concept.

[daedrdev]

much better would be execute_template(t"...")