3 ms·

> Agreed, although this doesn't work as well for HTML or SQL that doesn't fit on one line. PEP 750 t-strings literals work with python's tripe-quote syntax (an

> Agreed, although this doesn't work as well for HTML or SQL that doesn't fit on one line. PEP 750 t-strings literals work with python's tripe-quote syntax (and its lesser-used implicit string concat syntax): lots_of_html = t""" <div> <main> <h1>Hello</h1> </main> </div> """ My hope is that we'll quickly see the tooling ecosystem catch up and -- just like in JavaScript-land -- support syntax coloring and formatting specific types of content in t-strings, like HTML.

neilv 2y ago
Yeah, editor support will help a lot. Though the PEP's way of doing things doesn't specify the language of the template where the literal occurs, so detection of that might have to be kludged. (Or, in a sufficiently working program, an editor with semantic analysis access could use something like type inference in the Python side, to determine the language in a less-kludgey way.)
- davepeck 2y ago
  > doesn't specify the language of the template where the literal occurs Yeah, something we spent a bunch of time considering. In the end, we decided it probably needed to stay out of scope for the PEP. You're right that JavaScript has an easier time here. Most of the JS tools we looked at simply inspect the name of the tag and if it's (say) html, they attempt to color/format string content as HTML regardless of what the html() function actually does or the string's contents. Currently, tools like black have no knowledge of types. I'm guessing some amount of kludging is to be expected on day one. But my hope is over the long term, we'll see a story emerge for how annotations can indicate the expected content type.
kazinator 2y ago
But that will not apply proper HTML escaping to the evil script element, allowing injection, and allows tags not to be closed: lots_of_html = t""" <div> <main> <p>{evil}>/p> <main> </span> """
- pphysch 2y ago
  lot_of_html isn't a string literal with dangerous elements smooshed into the trusted scaffolding like an f-string would do. It's a template instance that still needs to be safely processed into a renderable string, e.g. by escaping whatever `evil` evaluates to and even validating the final HTML syntax.
  - kazinator 2y ago
    I can easily end up unsafely processed. It's a footgun. And why would you be validating HTML on the fly, when it's coming from your program, not as an input into it. Even if you can do it at program startup once for each template, it's still pointless overhead. The whole thing is wrongheaded; exactly the kind of stove-pipe people end up inventing when they don't have metaprogramming.
    - davepeck 2y ago
      > I can easily end up unsafely processed I’m curious how?
    - pphysch 1y ago
      You don't have to add HTML validation to your processing func, but you brought up invalid syntax up as an issue with string templating. > The whole thing is wrongheaded; exactly the kind of stove-pipe people end up inventing when they don't have metaprogramming. Python has many metaprogramming features. I don't think you understand this feature much less its motivation. How else would you go about adding language support for e.g. HTML and SQL within Python?
      - kazinator 1y ago
        On the contrary, I implemented a substantial facsimile of it in a Lisp dialect yesterday; see my comment history. 1> (load "template") nil 2> (let ((field "name") (table "customers")) (te `SELECT @field FROM @table`)) #S(template merge #<interpreted fun: lambda (#:self-0073)> strings #("SELECT " " FROM ") vals #("name" "customers")) 3> *2.(merge) "SELECT name FROM customers" 4> [*2.vals 0] "name" 5> (set [*2.vals 0] "id") "id" 6> *2.(merge) "SELECT id FROM customers" 7> (upd *2.vals (map upcase-str)) #("ID" "CUSTOMERS") 8> *2.(merge) "SELECT ID FROM CUSTOMERS" Unlike template strings, it was done in the language. There already are quasi-strings in the form of `...` syntax. We can quote that syntax (e.g. implicitly as a macro argument) and then pull apart its pieces to construct an object. It should work even in a years-out-of-date installation of the language. No new tooling is required; no changes to syntax highlighting in the editor, nothing. It's a parlor trick that doesn't have any uses. The structured log messages use case is the most promising, because it has a consumer which actually wants the interpolated pieces that it would otherwise have to hackily parse out. I predict that Python will eventually get dedicated HTML syntax: perhaps something that uses indentation to indicate element nesting. Let's "vibe pseudocode" a sketch: html: div (class='main' id='1'): p: "paragraph text" or whatever.

neilv 2y ago

Yeah, editor support will help a lot. Though the PEP's way of doing things doesn't specify the language of the template where the literal occurs, so detection of that might have to be kludged. (Or, in a sufficiently working program, an editor with semantic analysis access could use something like type inference in the Python side, to determine the language in a less-kludgey way.)

davepeck 2y ago
> doesn't specify the language of the template where the literal occurs Yeah, something we spent a bunch of time considering. In the end, we decided it probably needed to stay out of scope for the PEP. You're right that JavaScript has an easier time here. Most of the JS tools we looked at simply inspect the name of the tag and if it's (say) html, they attempt to color/format string content as HTML regardless of what the html() function actually does or the string's contents. Currently, tools like black have no knowledge of types. I'm guessing some amount of kludging is to be expected on day one. But my hope is over the long term, we'll see a story emerge for how annotations can indicate the expected content type.

kazinator 2y ago

But that will not apply proper HTML escaping to the evil script element, allowing injection, and allows tags not to be closed: lots_of_html = t""" <div> <main> <p>{evil}>/p> <main> </span> """

pphysch 2y ago
lot_of_html isn't a string literal with dangerous elements smooshed into the trusted scaffolding like an f-string would do. It's a template instance that still needs to be safely processed into a renderable string, e.g. by escaping whatever `evil` evaluates to and even validating the final HTML syntax.
- kazinator 2y ago
  I can easily end up unsafely processed. It's a footgun. And why would you be validating HTML on the fly, when it's coming from your program, not as an input into it. Even if you can do it at program startup once for each template, it's still pointless overhead. The whole thing is wrongheaded; exactly the kind of stove-pipe people end up inventing when they don't have metaprogramming.
  - davepeck 2y ago
    > I can easily end up unsafely processed I’m curious how?
  - pphysch 1y ago
    You don't have to add HTML validation to your processing func, but you brought up invalid syntax up as an issue with string templating. > The whole thing is wrongheaded; exactly the kind of stove-pipe people end up inventing when they don't have metaprogramming. Python has many metaprogramming features. I don't think you understand this feature much less its motivation. How else would you go about adding language support for e.g. HTML and SQL within Python?
    - kazinator 1y ago
      On the contrary, I implemented a substantial facsimile of it in a Lisp dialect yesterday; see my comment history. 1> (load "template") nil 2> (let ((field "name") (table "customers")) (te `SELECT @field FROM @table`)) #S(template merge #<interpreted fun: lambda (#:self-0073)> strings #("SELECT " " FROM ") vals #("name" "customers")) 3> *2.(merge) "SELECT name FROM customers" 4> [*2.vals 0] "name" 5> (set [*2.vals 0] "id") "id" 6> *2.(merge) "SELECT id FROM customers" 7> (upd *2.vals (map upcase-str)) #("ID" "CUSTOMERS") 8> *2.(merge) "SELECT ID FROM CUSTOMERS" Unlike template strings, it was done in the language. There already are quasi-strings in the form of `...` syntax. We can quote that syntax (e.g. implicitly as a macro argument) and then pull apart its pieces to construct an object. It should work even in a years-out-of-date installation of the language. No new tooling is required; no changes to syntax highlighting in the editor, nothing. It's a parlor trick that doesn't have any uses. The structured log messages use case is the most promising, because it has a consumer which actually wants the interpolated pieces that it would otherwise have to hackily parse out. I predict that Python will eventually get dedicated HTML syntax: perhaps something that uses indentation to indicate element nesting. Let's "vibe pseudocode" a sketch: html: div (class='main' id='1'): p: "paragraph text" or whatever.