One simple way to implement this in Python is with a tuple. Have your function return a tuple of: (status, result) where the status can be numeric or a string, and the result can be any Python data structure you fancy.

Here s an example, adapted from the module documentation. Server code:

from SimpleXMLRPCServer import SimpleXMLRPCServer
from SimpleXMLRPCServer import SimpleXMLRPCRequestHandler

# Restrict to a particular path.
class RequestHandler(SimpleXMLRPCRequestHandler):
    rpc_paths = ( /RPC2 ,)

# Create server
server = SimpleXMLRPCServer(("localhost", 8000),
                            requestHandler=RequestHandler)

def myfunction(x, y):
    status = 1
    result = [5, 6, [4, 5]]
    return (status, result)
server.register_function(myfunction)

# Run the server s main loop
server.serve_forever()

Client code:

import xmlrpclib

s = xmlrpclib.ServerProxy( http://localhost:8000 )
print s.myfunction(2, 4)

The server function returns a tuple

"in the C world, a function can return error code to represent the exit status, and use INOUT/OUT parameter to carry the actual fruit of the process"

1. Consider an exit status to be a hack. It s not a C-ism, it s a Linux-ism. C functions return exactly one value. C doesn t have exceptions, so there are several ways to indicate failure, all pretty bad.

   Exception handling is what s needed. Python and Java have this, and they don t need exit status.

   OS s however, still depend on exit status because shell scripting is still very primitive and some languages (like C) can t produce exceptions.

2. Consider in/out variables also to be a hack. This is a terrible hack because the function has multiple side-effects in addition to returning a value.

Both of these "features" aren t really the best design patterns to follow.

Ideally, a function is "idempotent" -- no matter how many times you call it, you get the same results. In/Out variables break idempotency in obscure, hard-to-debug ways.

You don t really need either of these features, that s why you don t see many best practices for implementing them.

The best practice is to return a value or raise an exception. If you need to return multiple values you return a tuple. If things didn t work, you don t return an exit status, you raise an exception.

Update. Since the remote process is basically RSH to run a remote command, you should do what remctl does.

You need to mimic: http://linux.die.net/man/1/remctl precisely. You have to write a Python client and server. The server returns a message with a status code (and any other summary, like run-time). The client exits with that same status code.