What are the pros and cons of PyRo and RPyC python libs?

YMMV, but here are my results from evaluating RPyC, Pyro4 and ZeroRPC for use on an upcoming project. Note that there are not in-depth tests, nor is this intended to be an in-depth review, just my notes on how well each works for the needs of my upcoming project.

ZeroRPC:

• quite a few dependencies
• very young project (main support from dotCloud)
• very little documentation
• can't access remote object's attributes, just methods
• Due to lack of attribute access, IPython tab completion does not work on remote objects

Pyro4:

• Python3 support
• Nice, plentiful documentation
• mature project
• No attribute access/IPython tab completion

Pyro3:

• support for attribute access (claimed in docs; have not verified)
• No Python3 support

RPyC:

• attribute access, IPython tab completion on remote objects
• Python3 support (claimed in docs; not yet verified)
• spotty documentation

FWIW:

I tend to like RPyC (maybe because it was my first? ;-), but it's documentation is sparse. It was my first exposure to an RPC, and it took me a long time to "grok" how to get things working. The author (Tomer) is very helpful and does respond to Qs on the Google RPyC list.

If you're new to RPC, I would suggest starting with Pyro and take advantage of its solid documentation to learn the ropes. Move on to RPyC, ZeroRPC, etc. as your needs require.

I personally find them roughly equivalent, but RPyC's author (here) claims more simplicity (and maybe for somebody not all that used to distributed computing he's got a point; I may be too used to it to make a good judge;-). Quoting him...:

although PYRO has a long list of considerable projects in its resumè, I find setting up a server too complicated, if you take into account the amount of code needed, registering objects, running name servers, etc. Not to mention the number of different concepts you have to consider (events, rebinding, with or without name servers, proxy vs. attribute-proxy, names have to be unique, etc.). And it's limited (remote objects must be picklable so you can't work with remote files, etc.). All in all, PYRO has too many special cases and is generally too complicated (yes, I consider this complicated). So of course I'm not an independent reviewer -- but judge for yourself. Isn't RPyC simpler and cleaner?

On the other side of the coin, PyRO does try to provide some security (which RPyC's author claim is too weak anyway, and underlies many of PyRO's claimed complications).

A more independent voice, David Mertz, offers here a good explanation of RPyC (PyRO has been around much longer and David points to previous articles covering it). The "classic mode" is the totally generally and simple and zero-security part, "essentially identical to Pyro (without Pyro's optional security framework)"; the "services mode" is more secure (everything not explicitly permitted is by default forbidden) and, David says, " the service mode is essentially RPC (for example, XML_RPC), modulo some details on calling conventions and implementation". Seems a fair assessment to me.

BTW, I'm not particularly fond of single-language RPC systems -- even if Python covers 99% of my needs (and it's not quite THAT high;-), I love the fact that I can use any language for the remaining 1%... I don't want to give that up at the RPC layer!-) I'd rather do e.g. JSON-RPC via this module, or the like...!-).