Few suggestions

[tsdev]

As playing for a longer time with transplant I have suggestions for a few minor improvements. Maybe you find some of the usefull.

• in transplant_remote.m calling nargout(msg('name')) instead of nargout(fun) solves the problem with class methods in some case, so I added this little extension to transplant_remote.m, maybe you like it:

[~, funType] = which(msg('name'));
funType = strsplit(funType,' ');
if numel(funType)==2 && strcmp(funType{2},'method')
    argTemp = msg('args');
    className = funType{1};
    if ~isempty(argTemp) && isa(argTemp{1},className)
        % the function name corresponds to the
        % class of the first argument
        resultsize = nargout(msg('name'));
    end
end

• python keyword arguments could be automatically translated to matlab string value pairs, such as mlab.myfun(option1=value1) would be called in Matlab myfun(option1,value1). You might not like it though due to ambiguity.
• in Matlab the usage of the struct data type is far more common than the usage of the containers.Map so it would be nice to make it a bit easyer to work with structures. For example using the MatlabStruct class in python should be applied recursively to all nested structures. Again it might be again an ambiguity problem.
• calling a chain of functions on large matrices or other objects makes transferring large amount of data multiple times between python and matlab, e.g.

A = mlab.myfun()
B = mlab.myfun2(A)
C = mlab.myfun3(B)

If A, B and C are large matrices the above command might be limited by the data transfer. It would be nice to specify per function call to keep the result in the proxy in matlab and send only a pointer to python as you are already doing it for objects. For example:

A = mlab.myfun(inproxy=True)
B = mlab.myfun2(A,inproxy=True)
C = mlab.myfun3(B,inproxy=True)

[tsdev]

I made a speed test on my system

This is just timing the command

A = m.zeros(pow(10,N),1)

It seems transferring and converting doubles of 100 MB takes about 1 s, it was 4 s on another computer compared to the negligible time it takes to create these matrices in Matlab. This shows that enabling keeping variables in the Matlab proxy would greatly increase the speed when Matlab commands are called in a chain.

[bastibe]

Thank you for these suggestions! They are greatly appreciated!

in transplant_remote.m calling nargout(msg('name')) instead of nargout(fun) solves the problem with class methods in some case, so I added this little extension to transplant_remote.m, maybe you like it:

Very cool! If I'm not mistaken, this could be implemented a bit simpler: 08478bb
Can you check if this works as intended?

python keyword arguments could be automatically translated to matlab string value pairs, such as mlab.myfun(option1=value1) would be called in Matlab myfun(option1,value1). You might not like it though due to ambiguity.

Sure, why not. This should be easy to implement, and I can't see any downside to it. I have an implementation in 2d68de5, which seems to work on my test cases. Does it work for yours as well?

in Matlab the usage of the struct data type is far more common than the usage of the containers.Map so it would be nice to make it a bit easyer to work with structures. For example using the MatlabStruct class in python should be applied recursively to all nested structures. Again it might be again an ambiguity problem.

This is a harder problem. The main issue is that Python dicts can use arbitrary keys, and Matlab structs can not. This is why I opted for Maps instead of structs. Now that I think about it, Python dicts support all kinds of things as keys, and not just strings, which still blows up Matlab, so maybe the current solution is not a good one, either.

Do you have an opinion on how to solve this problem better?

calling a chain of functions on large matrices or other objects makes transferring large amount of data multiple times between python and matlab, e.g. [...]

This is a very cool idea! The network delay is unavoidable, and in fact I am quite proud of Transplant's performance. Still, your solution would simplify many use cases. I have opened a new issue for this in #48, let's continue the discussion there.

[tsdev]

Thanks for going through my ideas. I checked 2d68de5 it works as intended, while I opened a new issue to discuss 08478bb.