How is this advantageous over str.format? [LWN.net]

How is this advantageous over str.format?

Posted Jan 23, 2025 18:58 UTC (Thu) by rrolls (subscriber, #151126)
In reply to: How is this advantageous over str.format? by siddh
Parent article: A revamped Python string-formatting proposal

It doesn't look particularly exciting in these textbook cases, but the benefits will quickly show themselves once you have more complicated real-world cases.

With t-strings, you could easily have something like this:

def render_item_row(item: Item) -> HTML:
  return HTML(t"<tr><td>{item.name}</td><td>{item.date}</td><td>{item.author}</td></tr>")

Your "equivalent" would look like this:

def render_item_row(item: Item) -> HTML:
  return HTML(
    "<tr><td>{name}</td><td>{date}</td><td>{author}</td></tr>",
    {"name": item.name, "date": item.date, "author": item.author}
  )

which is unwieldy, unintuitive, and has a lot of boilerplate... or perhaps you might do

def render_item_row(item: Item) -> HTML:
  return HTML(
    "<tr><td>{name}</td><td>{date}</td><td>{author}</td></tr>",
    dataclasses.asdict(item)
  )

if Item happened to be a dataclass, but then as well as that requirement, the code doesn't make it obvious that those fields actually exist in the class.

Additionally, if you are using code assist, the 1st code block above will immediately get a red squiggly under any nonexistent field. But in both the 2nd and 3rd cases, code assist would not be able to help you if the text between { } was incorrect, or (in the 2nd case) if the dict keys were incorrect.

to post comments

How is this advantageous over str.format?

Posted Jan 23, 2025 20:33 UTC (Thu) by siddh (subscriber, #169663) [Link] (1 responses)

> which is unwieldy, unintuitive, and has a lot of boilerplate...

It's not IMO. In fact for complex code you'd anyways have to create intermediary variables to make the code cleaner (what if name has to be item.original_name sometimes?).

I do agree t-strings looks cleaner, but from the passing to function POV, it just feels like new syntactic sugar to me for a function call.

Also, it's named "template" but IIUC it is just a locally bound object invalid outside of its scope, like you can't pass it around generically and have the vars substituted without wrapping in a function call which then leads to same thing.

So all-in-all the advantage just boils down to introducing the new type so str can be explicitly disallowed? For eg. sqlite3 could throw exception on using str. That will indeed force less mistakes in processing unsantised input where it's done, but may also make the already-assumed dumb programmer more careless...

But I do get your point now and appreciate it more. Thanks!

How is this advantageous over str.format?

Posted Jan 28, 2025 17:31 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

> IIUC it is just a locally bound object invalid outside of its scope, like you can't pass it around generically and have the vars substituted without wrapping in a function call which then leads to same thing.

You can indeed pass t-strings around arbitrarily, it's just that the vars are eagerly evaluated at construction time. Which is fine IMHO, because a lazy t-string would just be way too much magic for one bit of syntax (and you can always use a lambda if that's really what you wanted).