What is the current choice for doing RPC in Python?

Question

Actually, I've done some work with Pyro and RPyC, but there is more RPC implementation than these two. Can we make a list of them?

Native Python-based protocols:

• PyRo4 (Python Remote Objects)
• RPyC (Remote Python Call)
• Circuits

RPC frameworks with a lot of underlying protocols:

• Spyne (see lightning talk)

JSON-RPC based frameworks:

• python-symmetric-jsonrpc
• rpcbd
• Ladon
• jsonrpc2-zeromq-python

SOAP:

• ZSI
• SOAPpy
• Ladon
• Spyne

XML-RPC based frameworks:

• XMLRPC, using the xmlrpclib and SimpleXMLRPCServer modules in the standard library.

Others:

• WAMP (RPC + PubSub, JSON + MsgPack)
• Twisted Spread
• ZMQRPC (ZeroMQ and BSON based)
• VPy (Versile Python) - AGPLv3
• zerorpc (Python or Node.js, msgpack + ZeroMQ)
• gRPC

Solution 1

XML-RPC is part of the Python standard library:

• Python 2: xmlrpclib and SimpleXMLRPCServer
• Python 3: xmlrpc (both client and server)

Solution 2

Apache Thrift is a cross-language RPC option developed at Facebook. Works over sockets, function signatures are defined in text files in a language-independent way.

Solution 3

Since I've asked this question, I've started using python-symmetric-jsonrpc. It is quite good, can be used between python and non-python software and follow the JSON-RPC standard. But it lacks some examples.

Solution 4

You could try Ladon. It serves up multiple web server protocols at once so you can offer more flexibility at the client side.

http://pypi.python.org/pypi/ladon

Solution 5

There are some attempts at making SOAP work with python, but I haven't tested it much so I can't say if it is good or not.

SOAPy is one example.

View more solutions

Comments

[ddaa]

It really depends on the context. Internet? LAN? Website? Distributed computation? Quick prototype? Bandwidth? Size of messages?

[edomaur]

@silentghost : done. I prefer not to set "community wiki" by default, because sometimes, I am wrong :) @ddaa : Any. I am asking about RPC in general terms, if they have some pros/cons in specific contexts, please add them to the list.

[Mattias Nilsson]

I had the need to do "real" RPC a little while ago (The RFC 1050 kind) and the choices then didn't impress much, so I ended up having to do most of it myself. If anyone has a good alternative to that, I'd like to hear about it.

[RichVel]

For those wanting Python-to-Python RPC - PyRo 4 latest version doesn't support SSL, but PyRo 3 still does - both are all-Python so they support Python 2, Python 3, PyPy, Jython, and IronPython. RPyc does support SSL, while Circuits doesn't mention this.

[thrau]

For simple applications you could consider PyMQ which supports synchronous RPC over redis or posix IPC.

[Ryu]

Having used most of the SOAP frameworks and implemented one for doing reflection based RPC myself, my advice is simple - don't do that. If you don't need cross language communication + independent interface descriptions + mapping to custom classes, the complexity of SOAP will only be a headache. Even if you do need to use it, you'll need the experience to know what subset of SOAP is safe to use.

[Denis Otkidach]

SOAP is nightmare in general and especially in Python. Don't use it unless you are forced to.

[Mattias Nilsson]

My limited experience with SOAP agrees with the other comments here. xmlrpc often does everything I need.

[Denis Otkidach]

+1 to XML-RPC for simplicity, even accounting that SimpleXMLRPCServer lacks proper error handling.

[Roberto]

Thrift does not support Python 3 is not supported yet, that's a shame

[Equidamoid]

"Warning The xmlrpc.server module is not secure against maliciously constructed data.", so it has some pretty limited usecases.

[AmaChefe]

@Equidamoid If you need to parse untrusted or unauthenticated data see docs.python.org/2/library/xml.html#xml-vulnerabilities

[Marcus Müller]

Personal comment: Thrift is a maintenance nightmare. I've not seen two Linux distributions even use comparable configure flags. Not too long ago (when I built 0.10.0 from source), most of the features need to be disabled to make it build on "exotic" systems like current Ubuntu, Debian or Fedora. Datatype changes under the hood make C++ usage a mess of #ifdefs, and in the 12 years of existence, they've not managed to convince themselves their software is ready for a 1.0.0 release. I like the massive amount of languages supported, but I think that's their weakness: trying to do too much.

[Marcus Müller]

(I use thrift in a medium-sized GNU Project I maintain. @Roberto, thrift support Py3, at least by now.)

[Marcus Müller]

I'd really encourage people to really think about whether you really need a cross-language framework that literally tries to connect PHP to C++ to Java to Python to Erlang to Common Lisp to Haskell to Swift. These are different languages, for a reason, and Thrift needs to do compromises to find a common denominator. I'd argue that the vast majority of people really only needs to connect 1 or 2 different languages, and a slimmer framework would be preferable.