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

How is this advantageous over str.format?

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

What I meant was

    def html(t_str):
        final = ""
        
        for item in template:
            match item:
                case str() as s:
                    final += s
                case Interpolation() as i:
                    final += sanitise(i)

        return final

    evil = "[script]alert('evil')[script]"
    template = t"[p]{evil}[/p]"
    sanitised = html(template)

is equivalent to

    def html(given, args):
        for k, v in args.items():
            args[k] = sanitise(v)

        return given_str.format(**args)

    args = {"evil": "[script]alert('evil')[/script]"}
    template = "[p]{evil}[/p]"
    sanitised = html(template, args)

Whatever you said is equally applicable to the second case IIUC.

(Used [] instead of <> since LWN HTML comment parses it...)

to post comments

How is this advantageous over str.format?

Posted Jan 23, 2025 15:56 UTC (Thu) by daroc (editor, #160859) [Link] (4 responses)

You can use HTML entities (< and >) if you want to type < and > in comments. It is a little unwieldy to do the escaping yourself, but you get used to it.

How is this advantageous over str.format?

Posted Jan 23, 2025 19:06 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Can we get an MD mode for comments, please?

How is this advantageous over str.format?

Posted Jan 27, 2025 6:49 UTC (Mon) by rsidd (guest, #2582) [Link]

For the case of code, just working support for the PRE tag would be an improvement. > and < are generally permitted within PRE tags and verbatim code with unescaped symbols is allowed there. LWN supports PRE tags but doesn't allow these unescaped symbols.

MD mode

Posted Jan 29, 2025 10:05 UTC (Wed) by smurf (subscriber, #17840) [Link] (1 responses)

*Strongly* seconded.

But somewhat off topic here. ;-)

MD mode

Posted Jan 29, 2025 13:52 UTC (Wed) by daroc (editor, #160859) [Link]

Sorry, I probably should have replied to Cyberax — it's on my list, but our site-development time is currently being spent on a number of anti-bot measures, because we've seen a big surge in the new year.

We'll get to it at some point, though!

How is this advantageous over str.format?

Posted Jan 23, 2025 18:58 UTC (Thu) by rrolls (subscriber, #151126) [Link] (2 responses)

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.

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