a question regarding call-by-reference

[Claudio Grondi]

enjoying the view wrote:
> 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. Extremely simple
> and I've gotten it to mostly work, but I have one problem:
> call-by-reference parameters. An example:
> 
> A function like this:
> def sum(a, b):
>   return a + b
> 
> would yield a client stub like this (simplified):
> def sum(a, b):
>    send_message({'funcname': 'sum', 'args': (a, b)})
>    result = receive_message()
>    return result
> 
> Now, this works just fine. I get problems when I try to do something
> like this:
> def add_elm(list):
>    list.append('elm')
>    return
> 
> Imported normally this would work fine. The list given as a parameter
> would be one element larger. But when the stubs are generated, the
> function doesn't return anything and the list is appended in the server
> and the client-side list is left untouched. At first I thought the
> solution was easy, just return the changed parameters and place them in
> the parameter variables in the client stub:
> def add_elm(list):
>    send_message({'funcname': 'add_elm', 'args': (list)})
>    response = receive_message()
>    (list) = response.get('args')
>    return response.get('result')
> 
> The problem is, this doesn't work. The original list doesn't point to
> the changed list. I have been trying to figure this out and it seems
> that if I just assign to the list variable it just modifies the local
> (to the function) name space, and that those changes aren't reflected
> in the list in the original name space.
> 
> I believe there are some ways around this, but I haven't found one that
> would not require any special handling in either the code calling the
> client stub or the original functions. I want to maintain transparency.
> 
> etv
> 
I am not an expert, so maybe someone else can provide here a nice tricky 
solution, but I am quite sure, that there is no simple way around the 
described problem.
The only strategy which comes to my mind in this context is to use for 
all function arguments and return values only pickled objects which need 
to be unpickled on the other side. Probably some compression algorithm 
can help to keep the network traffic down in case large amount of data 
must be exchanged.

Claudio