PyRo和RPyC Python库的优缺点是什么？
我在找一个适合Python的远程过程调用引擎，发现了PyRo（Python远程对象）和RPyC（远程Python调用）这两个工具，它们都符合我的需求。
不过，我很好奇这两个工具有什么不同，它们各自的优缺点是什么呢？
2 个回答
这段内容是关于我对RPyC、Pyro4和ZeroRPC这三个工具的评估结果，目的是为了在即将到来的项目中使用。请注意，这里没有深入的测试，也不是详细的评测，只是我对每个工具在我项目需求下表现的简单记录。
ZeroRPC:
- 依赖的东西比较多
- 项目还很年轻（主要由dotCloud支持）
- 文档很少
- 不能访问远程对象的属性，只能调用方法
- 因为不能访问属性，所以在远程对象上使用IPython的自动补全功能不管用
Pyro4:
- 支持Python3
- 文档丰富且易懂
- 项目比较成熟
- 同样不能访问属性/IPython的自动补全功能不管用
Pyro3:
- 文档中说支持属性访问（但我还没验证过）
- 不支持Python3
RPyC:
- 可以访问属性，IPython的自动补全在远程对象上可以用
- 支持Python3（文档中说的；但还没验证）
- 文档不太完整
顺便说一句：
我个人比较喜欢RPyC（可能因为这是我第一次接触的工具？;-），但它的文档确实不够详细。它是我第一次接触RPC的工具，花了我很长时间才弄明白怎么使用。作者（Tomer）非常乐于助人，会在Google RPyC讨论组里回答问题。
如果你是RPC的新手，我建议你先从Pyro开始，利用它丰富的文档来学习基础知识。等你掌握了之后，再根据需要去尝试RPyC、ZeroRPC等其他工具。
我个人觉得这两者差不多，但RPyC的作者（在这里）认为RPyC更简单（也许对于那些不太熟悉分布式计算的人来说，他的观点是有道理的；我可能对这方面太熟悉了，没法客观判断;-）。他提到：
虽然PYRO有很多不错的项目在它的履历中，但我觉得设置一个服务器太复杂了，考虑到需要的代码量、注册对象、运行名称服务器等等。更不用说你需要考虑的不同概念有多少（事件、重新绑定、是否使用名称服务器、代理与属性代理、名称必须唯一等等）。而且它的限制也很多（远程对象必须是可序列化的，所以你不能处理远程文件等等）。总的来说，PYRO有太多特殊情况，整体上太复杂了（是的，我觉得这很复杂）。所以当然我不是一个独立的评审者——但你自己判断一下。RPyC难道不是更简单、更干净吗？
另一方面，PyRO确实尝试提供一些安全性（不过RPyC的作者认为这安全性也太弱了，这也是PyRO所声称的复杂性的原因之一）。
另一位独立的声音，David Mertz，在这里对RPyC做了很好的解释（PyRO出现的时间更久，David也提到了之前关于它的文章）。所谓的“经典模式”是完全通用、简单且没有安全性的部分，“本质上与Pyro相同（没有Pyro的可选安全框架）”；而“服务模式”则更安全（默认情况下，未明确允许的所有操作都是禁止的），David说，“服务模式本质上是RPC（例如，XML_RPC），只是一些调用约定和实现的细节有所不同”。我觉得这是个公平的评价。
顺便说一下，我并不是特别喜欢单语言的RPC系统——即使Python能满足我99%的需求（其实也没那么高;-），我还是喜欢能用其他语言处理剩下的1%……我不想在RPC层面放弃这个选择！-) 我宁愿通过JSON-RPC和这个模块来实现，或者类似的东西……!-).