Problem with old-style classes in xmlrpclib

[mschmitzer]

Me again with another strange problem: We use the raven package to report runtime errors to a sentry instance. When the raven client serializes objects it encounters on the stack, it probes them for a special __sentry__ property using __getattribute__. If the object in question happens to be a ServerProxy this goes wrong because the xmlrpc.ServerProxy base class is an old-style class and thus doesn't have a __getattribute__ method. This is particularly annoying in the (JSON)RPC case because unknown attributes are assumed to be RPC functions and thus called, leading to weird errors from the RPC service.

There are some obvious ways of hacking around this. You can just catch __getattribute__ (or something broader) in ServerProxy.__getattr__ and raise AttributeError. Or you could manually add a __getattribute__ method to ServerProxy. None of that seems particularly pretty, though.

Any ideas? Maybe ditch the xmlrpclib base? :smile:

[tcalmant]

Hi, IMHO, a "good enough" solution might be to add some checks in ServerProxy.__getattr__ to ignore all special methods (i.e. starting and ending by a double underscore). This would also sanitize the behavior of the proxy.

For example, for now, trying to get members like __call__, __name__ returns ServerProxy's one, whereas the other ones (__add__, __len__, etc.) are proxied.

The fact that it is a good or a bad thing is subject to debate, but I think those special methods shouldn't be accessible from the proxy. The most important reason for that being that those method can return references to remote objects, which have no meaning on client's side.

[mschmitzer]

Sounds reasonable. We here certainly won't miss the ability to have RPC functions with "dunder" names.

I'll prepare a patch.