lots_of_html = t"""
<div>
<main>
<p>{evil}>/p>
<main>
</span>
"""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.
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.
I’m curious how?
> 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?
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"
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"
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>"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):
...
> How is it any better
It renders all of the following problems unrepresentable: mismatched angle brackets, mismatched or unclosed tags, bad attribute syntax, injection.
No, that isn't how it works. The unprocessed version is not a `str` instance and doesn't implement `__str__`:
> This is because Template instances are intended to be used by template processing code, which may return a string or any other type. There is no canonical way to convert a Template to a string.
If you tried to use the Template directly as if it were a string, you'd get either a TypeError or completely malformed HTML (the `repr` of the Template instance, which would look very different).
>And why would you be validating HTML on the fly
You wouldn't be; you'd be escaping user-generated content that tries to break a page by including HTML markup.
... but let me assure you it's never the wrong one!