Maybe xmlrpclib should be modified to allow it to marshal subclasses of builtin types (ints, strings, etc).  Here's a simple example that demonstrates that it currently won't work with a subclass of str:

>>> import xmlrpclib
>>> class MyString(str):
...   pass
... 
>>> s = MyString("sdfsdfsdf")
>>> s
'sdfsdfsdf'
>>> s.__class__
<class '__main__.MyString'>
>>> xmlrpclib.dumps((s,))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/xmlrpclib.py", line 752, in dumps
    data = m.dumps(params)
  File "/usr/local/lib/python2.2/xmlrpclib.py", line 448, in dumps
    self.__dump(v)
  File "/usr/local/lib/python2.2/xmlrpclib.py", line 459, in __dump
    raise TypeError, "cannot marshal %s objects" % type(value)
TypeError: cannot marshal <class '__main__.MyString'> objects

Logged In: YES 
user_id=72053

1) anything but the base types aren't part of the
xmlrpc spec

2) be very very careful about unmarshalling any but basic
objects, because of possible security attacks.  See
item 471893 for some more info.

Logged In: YES 
user_id=44345

I don't think #471893 applies here.  While xmlrpclib will marshal the dict of an instance object, it is seen as a marshalled dict at the other end and would be unmarshalled as a dict without special effort on the part of the programmer.  XML-RPC only supports a small, fixed set of types: ints, booleans, floats, date-time strings, lists and dicts.

My concern with allowing XML-RPC marshalling of a subclass of strings (for example), is that the programmer might be led to believe their extra instance attributes would be marshalled as well.  While I submitted this bug report, I was simply recording someone else's observation.

Logged In: YES 
user_id=11375

Maybe we should just document that xmlrpclib won't handle 
subclasses?

Logged In: YES 
user_id=44345

closing this bug report.  Perhaps in the future 
subclasses of builtins could be marshalled, but extra
instance attributes wouldn't be.

libxmlrpclib.tex v 1.8 adds a note about this limitation
as suggested by Andrew.

How about revisiting this one? Although this behavior/limitation is documented, it is quite surprising to the user. FWIW, (simple)json module serializes subclasses of builtin types just as expected.

> FWIW, (simple)json module serializes subclasses of builtin types
> just as expected.

Does that round trip properly?  For instance, if you serialize an
instance of a list subclass does it unserialize as a list instance
or as the subclass?

Perhaps JSON has some way of supporting a user-defined set of types.
XML-RPC has no way to do that, and feeding in an instance of a
subtype then getting the base type out on the other end was deemed
a bad thing.

>> FWIW, (simple)json module serializes subclasses of builtin types
>> just as expected.
> Does that round trip properly?  For instance, if you serialize an
> instance of a list subclass does it unserialize as a list instance
> or as the subclass?

You get a list instance. So, at least without any additional work it does not round trip symmetrically. But IMO this is actually the expected result; subclasses of string should serialize like strings, subclasses of list like lists etc. And when you unserialize those without any additional magic, you get the builtin types, not the subclasses.