Python’s new t-strings

It feels a bit like "cheating" that new x-string features are built-in only. It would be cool to be able to do:

    from foo import bar
    bar"zoop"

A t-string is a literal for a Template object which is a data holder, it doesn't actually do anything, so you would simply call

    bar(t"zoop")

True. Then you could use

  sql"..."
  html"..."

for each of the given examples and achieve some runtime type safety.

Use a function?

    bar(“zoop”)

It’s just syntax, like we used to have

    print “foo” 

that later became

    print(“foo”)

And you'd end up with almost no improvement.

If you pass a "t-string" to a framework, it can force escaping.

What you suggest is to rely on escaping by the user (dev), who, if he was aware, would already escape.

Unless you'd suggest that it would still return a template, but tagged with a language.

This is exactly how Nim is. The f-string like equivalent uses a macro called "fmt" which has a short alias "&". So you can say:

    import std/strformat
    let world = "planet"
    echo &"hello {world}"

The regular expression module does a similar thing with a `re"regular expression"` syntax or std/pegs with peg"parsing expression grammar" and so on. There are probably numerous other examples.

In general, with user-defined operators and templates and macros, Nim has all kinds of Lisp-like facilities to extend the language, but with a more static focus which helps for both correctness and performance.

This was the original proposed idea in the PEP (750), but it changed overtime. There is a section in the PEP to explain why it changed to t-strings if you are interested.

meh, the difference between bar"zoop" and bar("zoop") isn't really big enough to be worth it.

I like F strings a lot, but for the most part I think all of the various X-strings should just be classes that take a string as an argument.

FWIW the JS equivalent is a template but tagged with a language. It has all the benefits of this template, but IDEs can easily syntax highlight the string. That seems like it would be a bit trickier to do with the Python one which is a shame.

In my own language design (nothing public yet - need to prioritize more practical things at the moment) this is definitely on the menu. Aside from a minimal set, keywords are implemented as compile-time macros; and it's intended that they can be extended, both "natively" and in the implementation language, by writing AST-manipulation code. But the handling of arithmetic expressions, as well as the broader line/block structure, is hard-coded. (I draw inspiration from both Python and the Lisp family.)

PEP 638 has always seemed to me like something of a generalization of the idea. But that really feels to me like a 4.0 feature, or rather something that needs to be designed for from the beginning. (Which is why I've done a bit of that in my own mind...)

No, you misunderstood that completely. They would still be like t-strings, but sql-strings are now a different type from html-strings. The escaping would be done by the library that offers the sql"..." functionality.