PyRo 和 RPyC python 库的优缺点是什么？

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

提问by edomaur

I am looking for a remote procedure call engine for Python and I've found that PyRo (Python Remote Object)and RPyC (Remote Python Call) are both the kind of thing I am searching for.

我正在寻找 Python 的远程过程调用引擎，我发现PyRo（Python 远程对象）和RPyC（远程 Python 调用）都是我正在寻找的东西。

However, I am curious to know how they compare to each other and what are their pros and cons ?

但是，我很想知道它们如何相互比较以及它们的优缺点是什么？

回答by Alex Martelli

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...:

我个人认为它们大致相同，但 RPyC 的作者（这里）声称更简单（也许对于那些不习惯分布式计算的人来说，他有一点；我可能太习惯了，无法做出好的判断；-）。引用他...：

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?

尽管 PYRO 在其简历中列出了一长串可观的项目，但如果考虑到所需的代码量、注册对象、运行名称服务器等，我觉得设置服务器太复杂了。更不用说不同概念的数量了您必须考虑（事件、重新绑定、使用或不使用名称服务器、代理与属性代理、名称必须是唯一的等）。而且它是有限的（远程对象必须是可pickle的，所以你不能使用远程文件等）。总而言之，PYRO 有太多的特殊情况，通常也太复杂了（是的，我认为这很复杂）。所以当然我不是一个独立的评论者——但你自己判断。RPyC 不是更简单更干净吗？

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).

另一方面，PyRO 确实试图提供一些安全性（无论如何 RPyC 的作者声称这太弱了，并且是 PyRO 声称的许多并发症的基础）。

A more independent voice, David Mertz, offers herea 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.

一个更独立的声音，大卫默茨，在这里对 RPyC提供了一个很好的解释（PyRO 已经存在了更长时间，大卫指出了以前涵盖它的文章）。“经典模式”是完全通用、简单、零安全的部分，“本质上与Pyro相同（没有Pyro可选的安全框架）”；“服务模式”更安全（默认情况下，所有未明确允许的都被禁止），大卫说，“服务模式本质上是 RPC（例如，XML_RPC），以调用约定和实现的一些细节为模”。对我来说似乎是一个公平的评估。

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-RPCvia thismodule, or the like...!-).

顺便说一句，我不是特别喜欢单语言 RPC 系统——即使 Python 满足了我 99% 的需求（而且它不是那么高；-），我喜欢这样一个事实，即我可以对其余 1 种语言使用任何语言%...我不想在 RPC 层放弃它！-) 我宁愿通过这个模块做JSON-RPC，或者类似的......！-)。

回答by JS.

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.

YMMV，但这是我评估 RPyC、Pyro4 和 ZeroRPC 以用于即将到来的项目的结果。请注意，这里没有深入的测试，也不打算进行深入的，只是我对每个测试如何满足我即将进行的项目的需求的说明。

ZeroRPC:

零RPC：

• 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

• 相当多的依赖
• 非常年轻的项目（dotCloud 的主要支持）
• 很少的文档
• 无法访问远程对象的属性，只能访问方法
• 由于缺乏属性访问，IPython 选项卡完成对远程对象不起作用

Pyro4:

火焰兵4：

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

• Python3 支持
• 漂亮，丰富的文档
• 成熟的项目
• 无属性访问/IPython 选项卡完成

Pyro3:

火焰兵3：

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

• 支持属性访问（在文档中声明；尚未验证）
• 不支持 Python3

RPyC:

RPyC：

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

• 属性访问，远程对象上的 IPython 选项卡完成
• Python3 支持（在文档中声明；尚未验证）
• 参差不齐的文件

FWIW:

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.

我倾向于喜欢 RPyC（也许是因为它是我的第一个？;-)，但它的文档很少。这是我第一次接触 RPC，我花了很长时间来“理解”如何让事情工作。作者 (Tomer) 非常乐于助人，并且确实对 Google RPyC 列表中的 Q 做出了回应。

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.

如果您不熟悉 RPC，我建议您从 Pyro 开始，并利用其可靠的文档来学习绳索。根据您的需要继续使用 RPyC、ZeroRPC 等。