Currently, an XMLRPC client communicating with a server running Python can make Python style calls but exceptions get collapsed into a standard FaultException making it difficult to program in a Pythonic style:

proxy = xmlrpc.client.ServerProxy("http://localhost:8000/")
try:
    value = proxy.lookup('somekey')
except xmlrpc.client.Fault as err:
    if err.faultCode == 1 and 'KeyError' in err.faultString:
        k = re.search(r":.(\w+)' not found$", err.faultString).groups(1)
        raise KeyError(k)
 
It would be better if we could do this automatically (search for a pure python exception of the same name and raise it instead of a Fault):

proxy = xmlrpc.client.ServerProxy("http://localhost:8000/", python_exceptions=True)

try:
   value = proxy.lookup('somekey')
except KeyError as e:
   ...

Here's a basic patch. I have two issues with it: the flag name used for enabling the exceptions seems too verbose (use_python_exceptions, I'm opened to new suggestions) and I don't know if the fallback to Fault exception if the remote exception is not known is the best way.

-1

This essentially gives the ability for an XMLRPC server to crash any python code that interfaces with them unless you catch _every_ single exception including ones like SystemExit, KeyboardInterupt, SyntaxError, StopIteration etc.

An XMLRPC server is not a trusted resources and providing this option is akin to providing an option to unpickle arbitrary data received over the wire as well.

Do you have a suggestion for white-listing or a fault-to-exception mapper?

The current API makes faults difficult to use in Python.

Well you could possibly whitelist some exceptions although I still think that's ultimately a bad idea because it means to prevent the remote server (or someone in the middle of the connection) from being able to crash your program with an arbitrary exception it means you'd need to catch _all_ the whitelisted exceptions.

You could possibly make exception subclasses that subclass the Fault exception _and_ whatever exception the remote server threw so you could get the advantages of both sides.

One flaw in this though is that the remote server doesn't need to be in Python, so trying to map errors from the remote server into python exceptions is only going to work *if* the remote server is in Python (and even then only if the exception is a built in one and not any other exception). Yanking the text out of the error message and trying to turn that into an exception is fundamentally wrong I believe. It's a bit like reading the response body of a HTTP request and doing simple string searching to raise arbitrary exceptions (In fact that's basically exactly what it is).