I think the specification is reasonably clear: createComment may not
throw an exception. The serializer must throw an exception. (Personally,
I think they have it round the wrong way - every time you write a
serializer you have to write code to do the check; if it was in
createComment, you'd only have to do it once. Never mind!)

The problem of compatibility is, as always, a nasty one: whether or not
to  potentially break code that previously worked.

In this case, I think modifying toxml (and the other serializing
functions in the same library) to throw an exception is pretty unlikely
to break existing code. The *only* way to trigger the error is if you
call createComment with bad text. Moreover, the programs which
"succeeded" before which now fail were almost certainly producing wrong
output before, which if it did not break downstream processing, would at
least produce strange bits of extra character data.

If the library is changed to throw an exception, at least it will alert
the author/maintainer to the problem.

I would estimate the expected number of programs to be broken by such a
change to be about 0. :-)

This is certainly not the first time in the history of software
development the break or not to break issue has come up. Is there a
precedent in the python libraries for how to deal with this kind of
issue? Can we add a quickAndBuggy = True default parameter to toxml,
then in a couple of releases make it mandatory, then in a couple of
further releases remove it and the old behaviour?

cheers,
Tom