Attached is a silly PTL template and test driver.  With Quixote 0.5 it
runs in 0.98 seconds.  With my development version of Quixote and
_q_markupclass = str it takes 1.06.  With a Python implementation of
Markup it takes 2.29.  With a C version of Markup it takes 1.05.

The overhead is smaller then I guessed.  I was thinking of adding an
optimization pass in the PTL compiler to transform 'str("literal
string")' into "literal string".  That optimization doesn't appear to be
worth the effort.

Based on these results,  I am planning to release this feature (probably
Quixote 0.6) without any __future__-like mechanism.  If you don't want
to use the Markup string type you will have to add '_q_markupclass =
str' to the top of your PTL modules.  If you aren't ready for this
feature then stick with 0.5.x.

I thought about having a release where the default _q_markupclass was
'str'.  The intention was that people could convert their applications
piecemeal.  In practice that don't work well.  If you are going to use
the Markup type then you need to use it consistently throughout your
application.

I have started to convert our big application to use the Markup string
type.  It's going quite well so far.  Most of the changes involve adding
str() calls to the few places that we need a genuine literal string in a
template.  There are not too many of these because the Markup type
behaves much like a string.  For example, "Markup('a') == 'a'" is true.
Other changes involve adding a explicit Markup() calls to .py modules
that generate HTML code.  Eventually I will have to go through and
remove redundant html_quote calls (since html_quote(Markup('a')) ===
Markup('a')).

--
Neil Schemenauer  | MEMS Exchange
Software Engineer                        | http://www.mems-exchange.org/