Any news on this one ?

If noone objects, I'd like to restore the old interface.

...

I noticed yesterday that the xmlrcplib.py version in CVS is incompatible with the version in Python 2.2: all the .dump_XXX() interfaces changed and now include a third argument.

Since the Marshaller can be subclassed, this breaks all existing application space subclasses extending or changing the default xmlrpclib behaviour.

I'd opt for moving back to the previous style of calling the write method via self.write.

-- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

Fredrik Lundh wrote:

mal 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. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

Any news on this one ?

If noone objects, I'd like to restore the old interface.

...

I noticed yesterday that the xmlrcplib.py version in CVS is incompatible with the version in Python 2.2: all the .dump_XXX() interfaces changed and now include a third argument.

Since the Marshaller can be subclassed, this breaks all existing application space subclasses extending or changing the default xmlrpclib behaviour.

I'd opt for moving back to the previous style of calling the write method via self.write.

-- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

Fredrik Lundh wrote:

mal 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. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/