Re: Re: Proposal: ptl_compile.register_preprocessor()

David Binger wrote:

 > Hi Graham,
 >
 >> -from ptl_compile import compile_template, PTL_EXT
 >> +from quixote.ptl.ptl_compile import compile_template, PTL_EXT
 >
 > Just checked in.

Thanks!

 >>  def parse(buf, filename='<string>'):
 >> +    for ext_proc in _external_preprocessors:
 >> +        buf = ext_proc(buf)
 >
 > ....
 > This change would not cause any problems as far as I know,
 > but I wonder if this will suffice.
 >
 > As you know, but others may not, the ptl compiler uses a simple
 > source code transformation to convert templates into something
 > that can be parsed by the python parser, and then the compiler
 > applies some transformations to the parse tree to get the desired
 > template behavior.

Yes, I had thought of going that route. My source-only approach is a
bit brute-force, and is weak in the corner-cases. Really, it was a
question of time available to scratch the itch; I had time for source
manipulation but not for parse-tree munging. But, now that I'm seeing
actual benefits from the prototype, I think I'll need to revisit the
implementation.  Maybe you could add a register_tree_transformer()
hook as well, to save me from asking later? :-)

Having both the source-transform and tree-transform hooks should give
any PTL hackers all they need to get the job done. But I'm not sure
whether, as a rule, the external transformers should get access to the
tree before or after ptl_compile does, though. Perhaps, rather than a
"register_" pattern, we could just put PTL's own transformers in a
pair of lists (source_transformers, tree_transformers) at the module
level; interested parties could manipulate the lists, inserting their
handlers in the appropriate places. Thoughts?

Thanks, David.

Graham