7 ms·

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"

masklinn 1y ago
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")
Timwi 1y ago
True. Then you could use sql"..." html"..." for each of the given examples and achieve some runtime type safety.
- jbverschoor 1y ago
  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.
  - mcintyre1994 1y ago
    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.
  - Timwi 1y ago
    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.
thund 1y ago
Use a function? bar(“zoop”) It’s just syntax, like we used to have print “foo” that later became print(“foo”)
cb321 1y ago
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.
nhumrich 1y ago
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.
- zahlman 1y ago
  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...)
dec0dedab0de 1y ago
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.
zahlman 1y ago
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.)

masklinn 1y ago

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

Timwi 1y ago

True. Then you could use sql"..." html"..." for each of the given examples and achieve some runtime type safety.

jbverschoor 1y ago
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.
- mcintyre1994 1y ago
  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.
- Timwi 1y ago
  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.

thund 1y ago

Use a function? bar(“zoop”) It’s just syntax, like we used to have print “foo” that later became print(“foo”)

cb321 1y ago

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.

nhumrich 1y ago

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.

zahlman 1y ago
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...)

dec0dedab0de 1y ago

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.

zahlman 1y ago

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