> I agree that it is annoying that htmltext instances cannot be used
> everywhere a string can be used.  However, I don't think it's

I, too, have been bitten by inadvertant htmltext that breaks things expecting
real strings.  The problem is that in many cases, htmltext is as good as
a string:

>>> {'hi': 'there'}[quixote.html.htmltext('hi')]
'there'

In other cases, it is not:

>>> 'hi-there'.split(quixote.html.htmltext('-'))
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: expected a character buffer object

I tentatively suggest that htmltext should always work or should never work, to
minimize surprises.  I don't think there is any way to have htmltexts turn into
strings when strings are expected, as in C++-ish automatic conversions, even if
that were a good idea.  Python's __coerce__ is intended for binary operators,
and it looks ever more deprecated than usual today.  So that leaves having them
never substitute for strings.  The dict works because htmltext defines
__hash__.  On the other hand, not having to str() dict keys in def [html] is
convenient, even if it can lull you into forgetting that htmltext is not a
string.

I think the solution is to just get used to writing [html] templates, and
seperate string-using code as much as possible.