Template string proposal

[henryiii]

Ever since t-strings were accepted, I've been wondering how they might be useful. There was quite a bit of discussion about how they would be useful for DOMs, but I didn't really have enough exposure to them to know how best to use them outside of the obvious (protecting variable substitution for SQL and similar). Now that they are out, and there's a library (tdom, an html library) using them¹, I think I have an idea of how they might be useful for rich. I have not implemented anything with them yet (even in Plumbum, which was mentioned during the t-string discussion), so please take this with a grain of salt, possibly a very large grain. But here's what I'm thinking, and I think it would enhance users control over formatting (if using 3.14+) quite nicely.

The thing I was doing that made me think of it was this snippet from scientific-python/cookie's sp-repo-review script sp-ruff-checks:

        kk = f'[green]"{k}"[/green],'
        rich.print(f"  {kk:23} [dim]# {v}[/dim]")

As you can see, there's a problem: the number inside v on the last row shouldn't be colored.

As for t-strings, they are a new prefix that doesn't turn into a string, but instead creates a new object. That object stores the alternating t-string text and t-string substitutions. The library can differentiate and choose how to render the value. It can even see how the value was typed, but that's not expected to be useful except for special cases (like = style formatting).

So, here's the proposal:

1. All rich methods that take strings would also support the new string.templatelib.Template object.
2. The text portion of the t-string would support rich's [] markup, but it would not assume any formatting: t"[dim]foo-123[/dim]" would be dim but would not color the 123 differently; you know it's a string typed by the user.
3. The value portion of the t-string could be:
   a) A string would be rendered as is, and not parsed for rich markup. x="[dim]foo-123[/dim]"; t"{x}" would render out as [dim]foo-123[/dim] and the number would not be colored either.
   b) A value would be colored as if it was passed directly to rich.print(); x = 123; t"foo-{x}" would render the 123 with color. Dataclasses would render as data classes. Etc.
   c) A t-string would also be supported, in which case it would render the inner one first.

Going back to the original example, this:

        kk = t'[green]"{k}"[/green],'
        rich.print(t"  {kk:23} [dim]# {v}[/dim]")

would now render correctly, since v is a string (the 23 might need to be a different number, as that includes the tags, not ANSI sequences; ideally it would the true length, without non-printing sequences).

Thoughts?

Footnotes

1. While tdom mostly does safe substitution, it also supports putting dicts in and rendering them out as attributes; I also see the structured logging example at https://realpython.com/python-t-strings/#writing-t-string-handlers, which I think helped inspire this idea. ↩