[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)

[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