[ZPT] What about Tassle ?

[Fred L. Drake, Jr.]

Florent Guillaume writes:
 > One has to realize that the current TAL is a really efficient
 > implementation. This comes with the price that extensibility is poor. I
 > wouldn't settle with anything noticably slower though.

Yes, there are significant trade-offs that have been made.  I don't
see a way to avoid that, though there may well be better trade-offs to
make.  (I'm open to changes, I just don't have any real time to spend
on them right now.)  I suspect very different tradeoffs could be made
by implementing substantial portions in C (Shane Hathaway did some
work along these lines), but I don't know if anyone has the time to do
that work at this point.

The very combination of the TAL and METAL processors into a single
piece of code is itself an optimization; it's always possible to
implement each language separately.  There are real performance costs
to that, though.

 > On the topic of TAL, it'd be nice if someone had time to work on a spec
 > for TAL v2 that incorporates the various remarks that have been made in
 > the past year or two about the semantic inconsitencies (nested macro
 > treatment, i18n attributes msgid syntax, etc.). The current implementors
 > of alternative implementations could chime in about what they extended,
 > what they had to work around, and what are the big semantic differences
 > they found.

Yes!  A single document that describes the desired behavior directly
and concisely would be much easier for an implementor to work with
than decipher the mass of email to the list.


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation