> Regular decorator functions is where my thinking was going also. My
> first concern with that is that it would incur a performance penalty
> with the functions being rewritten every time the module is loaded.
> I.e. not once when the source file is compiled to a .pyc. This could
> prove to be troublesome for large applications.

In any case, this approach won't work in python 3, where "useless"
literals
are removed from the code object, so we don't have them to use in
a template-revision.

A template revision includes two things:
1) the accumulation and return of the accumulated values, and
2) the automatic protection of all literals against more quoting.
I think we could use a conventional (but exotic) decorator for 2, but
not for 1.

In this case, we would have:

@quotedxml
def f():
     s = 'already quoted'
     s += f('already quoted')
     return s

or perhaps

@quotedxml
def f():
     s = []
     s.append(f('already quoted'))
     return join_xml(s)



>
> What if the decorator function was primarily a NOOP and just used to
> identify which functions/methods qpy will templatize? I.e. if a
> function/method is wrapped with a particular decorator from the qpy
> module, then it gets templatized during compilation. The decorator
> could also check to make sure that the function/method had indeed by
> templatized and throw an exception if not.

That's basically the same as what I proposed at the start of this
thread,
except that the "decorator" raises a SyntaxError if it is compiled by
the ordinary python compiler.

It is true that we could use a conventional decorator that just raises
an exception if it executes at all.   In this case, the file with
templates
would need to import those conventional decorators and make sure
that those names were never assigned any other values.  If the
decorators
did not execute as intended, you might not get a template compiled
as a non-template, and that would be very bad.

It seems better to be certain that you can't ever compile a file
with the wrong compiler.

> Would this allow files to end in .py?

It seems better to know up-front which compiler is required.