When using zope.publisher.xmlrpc.XMLRPCRequest with zope.publisher 6.1.0, date/time values are unmarshalled as xmlrpc.client.DateTime objects and binary values are unmarshalled as xmlrpc.client.Binary objects. Python's underlying xmlrpc library supports using the more convenient datetime.datetime and bytes types, but to preserve backward compatibility you have to call xmlrpc.client.loads(..., use_builtin_types=True) if you want this. Unfortunately, it isn't currently possible to ask XMLRPCRequest to unmarshal XML-RPC arguments like this, because its processInputs method does this with no convenient way to adjust it:
self._args, function = xmlrpclib.loads(lines)
xmlrpc.client.DateTime is particularly annoying, because you have to go through a rigmarole of converting it to a string and then running it through strptime to get a normal datetime object.
I'd like to have some way for applications to opt into the more convenient modern types, just as they can if they're using the standard xmlrpc library directly. The API is a bit awkward - arguments are deserialized before we know what view we're going to call, so it can't be done on a view-by-view basis - but perhaps we could add useBuiltinTypes = False to XMLRPCRequest, and then at least applications could set that to True if they're prepared to cope with getting datetime and bytes directly?
When using
zope.publisher.xmlrpc.XMLRPCRequestwith zope.publisher 6.1.0, date/time values are unmarshalled asxmlrpc.client.DateTimeobjects and binary values are unmarshalled asxmlrpc.client.Binaryobjects. Python's underlyingxmlrpclibrary supports using the more convenientdatetime.datetimeandbytestypes, but to preserve backward compatibility you have to callxmlrpc.client.loads(..., use_builtin_types=True)if you want this. Unfortunately, it isn't currently possible to askXMLRPCRequestto unmarshal XML-RPC arguments like this, because itsprocessInputsmethod does this with no convenient way to adjust it:xmlrpc.client.DateTimeis particularly annoying, because you have to go through a rigmarole of converting it to a string and then running it throughstrptimeto get a normaldatetimeobject.I'd like to have some way for applications to opt into the more convenient modern types, just as they can if they're using the standard
xmlrpclibrary directly. The API is a bit awkward - arguments are deserialized before we know what view we're going to call, so it can't be done on a view-by-view basis - but perhaps we could adduseBuiltinTypes = FalsetoXMLRPCRequest, and then at least applications could set that toTrueif they're prepared to cope with gettingdatetimeandbytesdirectly?