On Mon, 8 Oct 2007 15:49:44 -0400, David Binger 
wrote:
> In .qpy files, the special "template" functions are made
> known to the qpy compiler by using "[html]" or "[plain]"
> between a function name and the function's parameters.
> (This notation was developed before Python's decorator syntax
> was decided.)
>
> A pretty simple change to the qpy compiler makes it easy
> to support an alternative, decorator-like notation that
> looks like this:
>
> @[html]
> def f():
>      pass
>
> @[str]
> def g():
>      pass
>
> instead of
>
> def f [html] ():
>      pass
>
> def g [plain] ():
>      pass
>
> ------
>
> The "template decorator", @[html] or @[str] would be required
> to appear immediately preceding the "def".
>
> The notation of a template decorator looks like an ordinary
> decorator because, like an ordinary decorator, it changes the
> meaning of the following function definition.
> The difference is that the template decorator's action
> happens before the function definition is compiled.

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

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.

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?

> 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?

> Your thoughts?