python和haskell进程之间通信的ipc库是什么？ [关闭]答案

【问题标题】：what are the ipc libs to communicate between a python and an haskell process? [closed]python和haskell进程之间通信的ipc库是什么？ [关闭]
【发布时间】：2012-02-11 12:16:22
【问题描述】：

我正在考虑下一个项目的总体架构。对于后端，haskell 看起来非常合适，但不适用于前端，python 会更好并且可能更容易编码。繁重的计算将在 haskell 中完成，结果显示在使用 python 构建的 gui 中。

因此，我需要选择正确的管道和正确的格式来在这两个进程之间进行通信。

从 python 发送到 haskell 进程的消息将非常简单，就像一个包含几个但不同值的文档。（我认为可以使用 json。）

但是对于大（浮点）数组，从 haskell 到 python 进程的消息会更加沉重。这就是我需要更加小心的地方：我使用的任何库都需要在 python 中快速实现，并且在 haskell 中相当稳定。

那么，有哪些选择？

【问题讨论】：

是的，它没有给我任何有意义的结果。我认为它不是很容易搜索，原因有三个。首先，python 和 haskell 之间的通信不是很常见。其次，很难看出 haskell 生态系统中最好的库是什么（我不是很熟悉）。第三，对于包含大数组的消息来说，对小消息来说足够好的东西可能适用，也可能不适用。
真的吗？因为这个 google 搜索在前五个结果中至少返回了两个关于这个主题的页面：google.co.uk/search?q=haskell+python
@Marcin：这里只有一个，整个页面只有三个；但是，它们都是关于绑定/嵌入解决方案的，而这个问题主要是关于 IPC 的序列化格式。我认为敌意是没有道理的。这是一个合理的问题，有多种可能的答案。
@ehird：问起来是合理的，但 SO 中充满了来自即使是最基本的研究也懒得做的人的问题。这不是值得鼓励的事情。
@Marcin：嗯，因为你链接到的所有谷歌结果都没有直接相关，而且莱昂内尔说他们确实先尝试过搜索，我不确定你期望什么额外的研究；我已经尝试了一些其他搜索，但它们并没有太大的相关性，而且绝对没有像可用解决方案之间的比较那样。

标签： python haskell architecture ipc

【解决方案1】：

我会考虑使用 Haskell 的 cereal 或 blaze-builder 包来定义您自己的二进制序列化格式，然后编写代码以在 Python 中手动解包（例如使用 struct）。如果您有很多结构要传输，这可能会很痛苦，但如果只有一两个，那么这可能比找到两种语言都支持的二进制序列化格式更紧凑和更简单。

cereal 处理序列化和反序列化，但 blaze-builder 只处理序列化；另一方面，我认为 blaze-builder 更快。谷物的主要目的是以一种你不是特别挑剔的格式序列化一些东西，这样你以后可以用 Haskell 读回来，这意味着它广泛使用类型类，所以你必须小心使用标准序列化，它会做不受欢迎的事情，比如序列化任意 bignum Integers 而不是固定大小的整数，而 blaze-builder 更多的是关于自定义格式。尽管如此，使用自定义格式的谷物还是很容易的，如果您也想反序列化来自 Haskell 的结构，这是显而易见的选择。

快速浏览一下 Hackage 就会发现一个维护良好的 BSON 包；如果您的结构很复杂，这可能是一个不错的选择，但否则可能会过大。

我认为将 JSON 用于 Python→Haskell 传输可能是最好的主意；虽然您失去了双向使用相同序列化格式的好处，但 JSON 是非常标准的，并且在 Haskell 中得到了 aeson 的良好支持。如果您为 Haskell→Python 路线选择 BSON，那也可以。

我能想到的其他选择：

Apache Thrift on Hackage 有两个名称容易混淆的绑定：Thrift 和 thrift；似乎前者已被弃用，取而代之的是后者。不过，我对 Thrift 一无所知，所以我不能说这是否有帮助。
您可以在 Haskell 进程中使用 cpython 或 MissingPy embed the Python code（尽管后者似乎未维护）。
您可以使用 FFI 从 Haskell 导出函数，然后使用 ctypes 从 Python 导入它们。

【讨论】：

我认为你的意思的包叫做“cpython”而不是“haskell-cpython”。
@dflemstr：哦，谢谢；我链接的文章将其称为后者。
我想避免第一个版本/原型的不必要的复杂性。嵌入（也可以使用cython 完成）增加了一层复杂性。 IPC 和保持这两个进程分开对我来说似乎更直接，并为其他前端打开了大门。
（记录一下：你的答案和上面的本一样好，但我只能分配一次）

【解决方案2】：

我在我们公司使用谷歌的协议缓冲区而不是 zeromq。在 python、C++ 和 C# 代码之间转换数据非常愉快，我也成功地玩过 haskell。

基本上你可以把它分成两个问题，序列化和传输。

正如 ehird 提到他们的答案一样，有多种序列化选项。我会推荐经常使用它的协议缓冲区，但我听说过关于 thrift 的好消息，而且还有 msgpack.org，这看起来很可靠。

运输方面我推荐 zeromq，太棒了！它支持多种消息传递模式，而且速度很快。这是管道库的 zmq 资源和接收器的一个小例子（我还没有发布它）： https://github.com/boothead/zeromq-conduit

【讨论】：

其实我刚才又看了一下msgpack，RPC的东西看起来很不错。 RPC 在 protobuf 和 python 中有点痛苦。
不幸的是，hprotoc 包没有导出任何模块，并且protocol-buffers 没有在最新版本中构建；这些是我在 Hackage 上找到的唯一协议缓冲区库。所以我不确定使用 Haskell 的协议缓冲区是否实用......
IIRC，protocol buffer lib 发布时，在 python 中非常慢（python lib 是纯 python）。你知道这是否已经改变了吗？编辑：刚刚得到eihrd评论，我想如果haskell版本没有更新，这会排除pbuffers。我会尝试联系 lib 维护者。
@LionelBarret，PB 对于我在 python 中的用途来说已经足够快了，但是绝对速度不是我们的目标...... Greplin 发布了一个更快的协议缓冲区包：github.com/Greplin/fast-python-pb。对 protocol-buffers 包感到羞耻，我前一阵子用过，但不是很认真