Thomas Conway added the comment: 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 __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1390> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
