> My first reaction is that "@[html]/def f()" looks deceivingly
> identical to
> the standard python syntax. The "def f [html] ()" variation is to me
> visually more obvious that this is not a standard python function.
> Maybe
> only because I am used to it...

A nice thing about the @[html] notation is that code colorizors
will have an easier time colorizing the "def f():" properly.
Another nice thing for us is that our spacing convention, of using
no space between a function name and the parameters, can apply
to all functions.

>
> Another point -- is it really "html" here, or would it be more
> correct to
> use a more general "xml" as identifier? What is being done is really
> simplifying xml-escaping, there is no particular html-specific
> knowledge.

I think this is a very interesting point.
Maybe @[xml] and @[str] should be our supported template decorators.

>
> Is xml the only template type that is needed? Has anyone ever
> encountered
> other string escaping use cases? Things that come to mind are "url"
> and
> "json", maybe even "sql"... they happen a lot less frequently, but
> they
> each have their own escaping logic. Well, json is only useful as a
> conceptual example as I cannot really see any usage for builting
> json by
> combining strings... Anyhow, is it easy to add support for other
> template
> types in qpy?

There is a pattern to follow, but there is no support at all for
extending it.
(Assuming that you want the kind of performance we enjoy with the
current templates.)

>
> > Note that both notations are syntax errors for the ordinary
> > Python compiler, and this is essential, since it would be
> > very bad to have templates accidentally compiled with the
> > wrong compiler.
>
> Is this really true? It would be a pity... Is it at all technically
> possible (however complex) to not deviate at all from standard python
> syntax, i.e. .qpy files become normal .py files, and a regular python
> decorator can process the function code body to return another
> function? Is
> there a limitation I am not aware of?

The only possibility I can think of would be to have the decorator
actually replace the code
object of the function it decorates with a modified code object.