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

_______________________________________________
Quixote-users mailing list
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/quixote-users

Reply via email to