←back to thread

620 points tambourine_man | 1 comments | | HN request time: 0.216s | source
Show context
serbuvlad ◴[] 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 #
mikeholler ◴[] No.43752117[source]
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}")
replies(2): >>43752225 #>>43753358 #
notatoad ◴[] No.43753358[source]
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.

replies(1): >>43754592 #
gls2ro ◴[] No.43754592[source]
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)

replies(2): >>43754870 #>>43758950 #
1. notatoad ◴[] No.43758950[source]
>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.