"enjoying the view" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I am working on a school project, trying to build a simple RPC stub
> generator. The idea is that the generator takes a normal python file
> with functions defined in it and produces a client and server stub. The
> client stub has the same functions defined, but they just connect to
> the server and ask it to call the desired functions. The server stub is
> a server listening for incoming requests and dispatching them to the
> appropriate functions and sending back the results.
<snip>
One thing you might try is iterating over the arguments and doing special
handling for lists and dicts, which can be updated within the called module.
Using your example (changing 'list' to 'listarg' to avoid confusion):
def add_elm(listarg):
listarg.append('elm')
return
Generate code like:
def add_elm(listarg):
send_message({'funcname': 'add_elm', 'args': (listarg)})
response = receive_message()
listarg[:] = response.get('args')[0][:]
return response.get('result')
If the listargs get long/complicated, you might be doing a lot of data
copying at the cost of performance (especially since this is a defensive
copy - you don't *know* that the list was updated in the server in the first
place - I guess you could test first with "if response.get('args')[0] !=
listarg:" or something).
For dicts, do:
dictarg.update(response.get('args')[n])
This will be a little cheaper than just total replacement of the contents,
which is what the list [:] slice will do.
But this special-case handling only works for lists and dicts (don't know
how you would handle tuples or scalar variables), you quickly run into other
problems with passing objects. I'm taking you at your word that you are
creating a *simple* RPC stub generator. At this point, you can generate
stubs for methods that do not update their arguments, or for methods that
pass lists or dicts. I've used CORBA in the past, and this is similar to
using a subset of the full parameter functionality, such as using only "in"
parameters (as opposed to "out" or "inout"). That is, instead of defining a
method that modifies its parameter value, have the new value returned by the
function. Python actually helps you here, since it is so easy to pass back
a tuple of values from a function.
This kind of parameter marshalling/unmarshalling gets complicated quickly.
You are already very near the edge of non-intrusiveness on the client and
server sides - to get more features, you'll need to start adding some
aspects of parameter passing mechanisms (such as CORBA's in/out/inout
keywords), and object marshalling conventions (such as requiring objects
that are passed to implement compare() and update() or copy() methods).
-- Paul
--
http://mail.python.org/mailman/listinfo/python-list
