Neil Schemenauer wrote:

> Unfortunately it looks like it is going to cost more than 2.1
> compatibility.  Python string objects include the string data as
> part of the object (rather than referencing a char array).  The
> current htmltext object just references a string object.  If it
> becomes a string subtype it must copy the data from the string.
> Also, converting the htmltext object back to a string would also
> require a copy.  I haven't done any testing but I expect all that
> coping will have a performance impact.


Neil, I'm not sure if your sole motivation for subclassing htmltext from str
was to eliminate the need to 'cast' strings in PTL templates. Certainly this is
an excellent reason to do it, but perhaps you had more on your mind?

I wonder whether a 'cheap trick' might help us all out... since backticks are
deprecated in Python, perhaps we could put them to good use in PTL:

def proposed_syntax [html] (req):
     "this is htmltext, of course"
     `but this is a string, note the ticks`
     call_some_function("with htmltext parameter")
     call_another_function(`with string parameter`)

Not a bad compromise, IMO: This would read as "a bunch of strings" to the
casual reader; the seasoned Quixotista would know to read backticks as str()
delimiters.

It's still deceptively easy to type some_function('with quotes') in PTL, and
have it behave unexpectedly. Your original idea sounds like it would solve this
problem in the best possible way. But until then, I'd much rather use backticks
in my templates than litter them with str(...) wrappers. (And I'm guessing that
this would be an inexpensive modification to the PTL parser.)

Just a thought,

-- Graham