4 ms·

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 wr

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 2y 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.
- pphysch 2y ago
  > Unlike template strings, it was done in the language. This is a disingenuous way to compare a LISP with a language that values syntactic convention and strives to be readable and maintainable by more than one person. > I predict that Python will eventually get dedicated HTML syntax: How do you assign this result to a variable? How is this any better than content: HTML = t"<p>Hello {name}</p>"
  - kazinator 2y ago
    It's a true statement; I made a usable construct that causes template strings to be turned into objects, rather than to perform the string substitution. I did it without changing any syntax, or have to ship a new version of the language. Python has to ship a new version for this; there is no way for existing installations to use the code. I don't have to change anything in my editor setup. So who is it that values syntactic convention? t"abc" is a syntax errror in vast numbers of existing Python installations; how can we call it convention? > How do you assign this result to a variable? That's to be worked out. The "html:" fantasy construct could have a way to do that. When you think of assigning to a variable, the first thing that comes to mind is "a = b" syntax. But, look, the define construct in Python also assigns to a variable: define fun(arg): ... The imagined html construct could have arguments like to assign an object to a variable, or just spin out textual HTML into a specified stream. I don't want to get into it, but there are obvious ways it could be done such that it hits all sorts of requirements. > How is it any better It renders all of the following problems unrepresentable: mismatched angle brackets, mismatched or unclosed tags, bad attribute syntax, injection.

kazinator 2y 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.

pphysch 2y ago
> Unlike template strings, it was done in the language. This is a disingenuous way to compare a LISP with a language that values syntactic convention and strives to be readable and maintainable by more than one person. > I predict that Python will eventually get dedicated HTML syntax: How do you assign this result to a variable? How is this any better than content: HTML = t"<p>Hello {name}</p>"
- kazinator 2y ago
  It's a true statement; I made a usable construct that causes template strings to be turned into objects, rather than to perform the string substitution. I did it without changing any syntax, or have to ship a new version of the language. Python has to ship a new version for this; there is no way for existing installations to use the code. I don't have to change anything in my editor setup. So who is it that values syntactic convention? t"abc" is a syntax errror in vast numbers of existing Python installations; how can we call it convention? > How do you assign this result to a variable? That's to be worked out. The "html:" fantasy construct could have a way to do that. When you think of assigning to a variable, the first thing that comes to mind is "a = b" syntax. But, look, the define construct in Python also assigns to a variable: define fun(arg): ... The imagined html construct could have arguments like to assign an object to a variable, or just spin out textual HTML into a specified stream. I don't want to get into it, but there are obvious ways it could be done such that it hits all sorts of requirements. > How is it any better It renders all of the following problems unrepresentable: mismatched angle brackets, mismatched or unclosed tags, bad attribute syntax, injection.