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.








_______________________________________________
QP mailing list
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/qp

Reply via email to