Fredrik Lundh wrote:
Any news on this one ?
If noone objects, I'd like to restore the old interface.
the dump methods are an internal implementation details, and are only accessed through an internal dispatcher table. even if you override them, the marshaller won't use your new methods.
If I subclass the Marshaller and Unmarshaller and then use the subclasses, it would :-)
so what exactly is your use case?
I needed to adapt the type mapping in xmlrpclib a bit to better fit our needs. This is done by adding a few more methods to the Marshaller and Unmarshaller (it's a hack, but the module doesn't allow any other method, AFAIK):
def install_xmlrpclib_addons(xmlrpclib): m = xmlrpclib.Marshaller m.dump_datetime = _dump_datetime m.dispatch[DateTime.DateTimeType] = m.dump_datetime m.dump_buffer = _dump_buffer m.dispatch[types.BufferType] = m.dump_buffer m.dump_int = _dump_int m.dispatch[types.IntType] = m.dump_int u = xmlrpclib.Unmarshaller u.end_dateTime = _load_datetime u.dispatch['dateTime.iso8601'] = u.end_dateTime u.end_base64 = _load_buffer u.dispatch['base64'] = u.end_base64 u.end_boolean = _load_boolean u.dispatch['boolean'] = u.end_boolean
(and whatever you did to make that use case work, how do I stop you from doing the same thing with some other internal part of the standard library? ;-)
It would be nice to open up the module a little more so that hacks like the one above are not necessary, e.g. by making the used classes parameters to the loads/dumps functions.
Then you'd run into the same problem, though, since now subclasses would need to access the dump/load methods.
PS: Standard support for None would be nice to have in xmlrpclib... at least for the Marshalling side, since this is a very common problem with xmlrpc.