Prior versions of xmlrpclib.loads would raise an exception when passed
malformed documents:

exarkun@bigdog24:~/_trial_temp$ python2.4 -c 'from xmlrpclib import
loads; loads("\x00\n<methodResponse>\n <params>\n  <param>\n  </param>\n
</params>\n</methodResponse>\n")'
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/usr/lib/python2.4/xmlrpclib.py", line 1079, in loads
    p.feed(data)
  File "/usr/lib/python2.4/xmlrpclib.py", line 527, in feed
    self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 2,
column 0

However, as of the most recent Python 2.5 and Python 2.6 point releases,
this is no longer the case:

exarkun@bigdog24:/_trial_temp$ python2.5 -c 'from xmlrpclib import
loads; loads("\x00\n<methodResponse>\n <params>\n <param>\n </param>\n
</params>\n</methodResponse>\n")'
exarkun@bigdog24:/_trial_temp$ python2.6 -c 'from xmlrpclib import
loads; loads("\x00\n<methodResponse>\n <params>\n <param>\n </param>\n
</params>\n</methodResponse>\n")'
exarkun@bigdog24:~/_trial_temp$

Previous versions of Python 2.5 and Python 2.6 did not exhibit this
misbehavior.

This actually appears to be an issue with the sgmlop-based parser, not
the expat-based parser. After removing sgmlop, the exception-raising
behavior is restored.

Perhaps this bug should be closed as invalid, then. Only, I wonder if
this is the right bug tracker to use for sgmlop, or if it has one
somewhere else?

sgmlop doesn't do much validation; to quote the homepage: "[sgmlop] is
tolerant, and happily accepts XML-like data that are not well-formed. If
you need strictness, use another parser."

But given that Python ships with cElementTree these days, and
cElementTree's XMLParser (based on expat) is faster than both sgmlop and
pyexpat, maybe it's time to remove sgmlop support from xmlrpclib...

maybe it's time to remove sgmlop support from xmlrpclib...

+1

Here's a patch which removes sgmlop support from xmlrpclib.

Applied in r73201, r73202.