Most active commenters

    ←back to thread

    Python’s new t-strings

    (davepeck.org)
    620 points tambourine_man | 11 comments | 21 Apr 25 04:31 UTC | HN request time: 0.734s | source | bottom
    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 #
    1. mikeholler ◴[21 Apr 25 14:01 UTC] 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 #
    2. fzzzy ◴[21 Apr 25 14:11 UTC] No.43752225[source]▶
    But won't the f string version fail loudly because there's no name parameter?
    replies(1): >>43752231 #
    3. benwilber0 ◴[21 Apr 25 14:12 UTC] No.43752231[source]▶
    the {name} parameter is in the locals() dict like it always is
    replies(1): >>43752248 #
    4. fzzzy ◴[21 Apr 25 14:14 UTC] No.43752248{3}[source]▶
    Good point. Perhaps the database api could refuse strings and require Templates.
    replies(1): >>43753252 #
    5. bshacklett ◴[21 Apr 25 15:44 UTC] No.43753252{4}[source]▶
    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.
    replies(2): >>43755459 #>>43769208 #
    6. notatoad ◴[21 Apr 25 15:54 UTC] 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 #
    7. gls2ro ◴[21 Apr 25 17:55 UTC] 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 #
    8. masklinn ◴[21 Apr 25 18:21 UTC] No.43754870{3}[source]▶
    > 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.

    9. daedrdev ◴[21 Apr 25 19:19 UTC] No.43755459{5}[source]▶
    much better would be execute_template(t"...")
    10. notatoad ◴[22 Apr 25 03:53 UTC] No.43758950{3}[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.

    11. dragonwriter ◴[23 Apr 25 06:25 UTC] No.43769208{5}[source]▶
    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.