Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XMLRPCRequest doesn't support unmarshalling arguments using builtin types #71

Open
cjwatson opened this issue Mar 8, 2023 · 0 comments

Comments

@cjwatson
Copy link
Contributor

cjwatson commented Mar 8, 2023

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant