140

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:

RPC frameworks with a lot of underlying protocols:

JSON-RPC based frameworks:

SOAP:

XML-RPC based frameworks:

Others:

gmagno
  • 1,770
  • 1
  • 19
  • 40
edomaur
  • 1,397
  • 4
  • 23
  • 38
  • 4
    It really depends on the context. Internet? LAN? Website? Distributed computation? Quick prototype? Bandwidth? Size of messages? – ddaa Dec 10 '09 at 10:03
  • @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. – edomaur Dec 10 '09 at 10:12
  • 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. – Mattias Nilsson Dec 10 '09 at 10:29
  • 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. – RichVel Aug 20 '14 at 05:58
  • For simple applications you could consider [PyMQ](https://github.com/thrau/pymq) which supports synchronous RPC over redis or posix IPC. – thrau Oct 25 '20 at 20:02

8 Answers8

39

XML-RPC is part of the Python standard library:

Asclepius
  • 57,944
  • 17
  • 167
  • 143
Pär Wieslander
  • 28,374
  • 7
  • 55
  • 54
  • +1 to XML-RPC for simplicity, even accounting that SimpleXMLRPCServer lacks proper error handling. – Denis Otkidach Dec 11 '09 at 18:20
  • 1
    "Warning The xmlrpc.server module is not secure against maliciously constructed data.", so it has some pretty limited usecases. – Equidamoid Jun 28 '17 at 08:02
  • 1
    @Equidamoid If you need to parse untrusted or unauthenticated data see https://docs.python.org/2/library/xml.html#xml-vulnerabilities – AmaChefe Aug 10 '17 at 15:17
17

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.

RemcoGerlich
  • 30,470
  • 6
  • 61
  • 79
  • Thrift does not support Python 3 is not supported yet, that's a shame – Roberto Oct 25 '16 at 14:32
  • 2
    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 `#ifdef`s, 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 Aug 09 '19 at 09:07
  • (I use thrift in a medium-sized GNU Project I maintain. @Roberto, thrift support Py3, at least by now.) – Marcus Müller Aug 09 '19 at 09:08
  • 1
    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. – Marcus Müller Aug 09 '19 at 09:15
7

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.

Asclepius
  • 57,944
  • 17
  • 167
  • 143
edomaur
  • 1,397
  • 4
  • 23
  • 38
6

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

Jakob
  • 1
  • 1
  • 1
3

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.

Mattias Nilsson
  • 3,639
  • 1
  • 22
  • 29
  • 3
    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. – Ants Aasma Dec 10 '09 at 11:13
  • 4
    SOAP is nightmare in general and especially in Python. Don't use it unless you are forced to. – Denis Otkidach Dec 10 '09 at 11:31
  • 4
    My limited experience with SOAP agrees with the other comments here. xmlrpc often does everything I need. – Mattias Nilsson Dec 10 '09 at 13:38
3

We are developing Versile Python (VPy), an implementation for python 2.6+ and 3.x of a new ORB/RPC framework. Functional AGPL dev releases for review and testing are available. VPy has native python capabilities similar to PyRo and RPyC via a general native objects layer (code example). The product is designed for platform-independent remote object interaction for implementations of Versile Platform.

Full disclosure: I work for the company developing VPy.

Versile
  • 308
  • 1
  • 4
2

maybe ZSI which implements SOAP. I used the stub generator and It worked properly. The only problem I encountered is about doing SOAP throught HTTPS.

Phil
  • 11
  • 1
1

You missed out omniORB. This is a pretty full CORBA implementation, so you can also use it to talk to other languages that have CORBA support.

Dave Kirby
  • 25,806
  • 5
  • 67
  • 84