On Wed, Oct 29, 2003 at 08:31:51AM -0700, Jonathan Corbet wrote:
> I've been so often annoyed by this that I had thought about trying
> to do something like that myself.  The non-stringness of htmltext
> can leave little traps in your code that require truly
> comprehensive coverage testing to find.  So, in other words, I
> very much approve of this change.

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.

I can avoid some of the copying but it's not pretty.  I would have
to re-implement a lot of the things that string object already does.
Another option is to keep htmltext as a distinct type but implement
the buffer API.  A few things accept any object that implements it
(rather than just strings).  I've already implemented the buffer
interface.  Unfortunately it doesn't solve the original problem.
Lots of things want a string and won't accept the buffer interface.

Right now, I'm not feeling motivated to make htmltext a str
subtype.

  Neil