如何使用python将Python包公开给C#。Net vs ZeroMQ或其他

Question

我正在开发一个用Python3编写的应用程序，它由一个Python库/包（包含核心功能）和一个Python应用程序组成，该应用程序将提供cli shell并处理用户命令。

此外，Python包中包含的功能必须暴露给用C#（使用Microsoft. Net框架）编写的现有gui应用程序。

我已经对如何做到这一点做了相当多的研究，并提出了一些潜在的解决方案。

1. 使用 Python.Net 在 C# 应用程序中实现 Python 脚本，该脚本导入我的 python 包并调用所需的方法/属性。我还没有能够让它自己在 monodevelopment 上工作，但这似乎是一个受欢迎的选择，尽管没有太多关于我的用例的文档。
2. 使用 CFFI 将我的 Python 库嵌入为 DLL。此选项似乎不需要很多工作，但很难看出我将如何维护我的接口/我向使用 C# 中的 DLL 的人公开的内容。此选项似乎也没有得到与我的用例相关的许多文档的支持。
3. 创建一个小型的 Python 应用程序，它导入我的 python 包并通过 ZeroMQ 或 gRPC 公开其功能。这似乎是具有大量文档的最灵活的选项，但是我担心延迟，因为最终此工具用于硬件控制。

注意 我不精通 C#，将用 Linux 进行大部分开发。

我真的希望获得有关哪个选项将在我的库的干净界面和低延迟/良好性能（强调后面）之间提供最佳平衡的反馈。

Answer 1

你说你的python应用程序有一个cli，所以另一个潜在的选择是让你的C#应用程序通过命令行与你的python应用程序交互。

您需要通过命令行参数公开python的功能(您可能已经这样做了)，并且您的python应用程序需要能够以json数据的形式返回结果，这可能是从C#中使用它的最简单的方法。

这完全取决于C# gui和python应用程序之间的交互需要有多复杂。

Answer 2

_{感谢您添加有关相当广泛的延迟上限的详细信息〜10 .. 100 [ms]}

...这实际上是在替换以前在 C 中实现的东西。这个想法是，如果库的接口层和cli是用Python实现的，那么用户将更容易为其用例构建核心功能。一些要求更高的控制回路可能必须实现为静态 C 库或 rust 库，我们会用 python 调用它们。无论如何，顶层仍然是用 Python 实现的，它必须与 C# 接口
_{（ = 这里最重要的收获......
需要了解两者
希望拥有用户扩展的便利性的成本}

为了安全起见

映射您的控制系统-内部生态系统_（资源）

没有对玩具应有的理解，没有人能决定足够合适的建筑。

理解延迟驱动设备中的设备景观需要我们首先知道（读取测试基准，它也是被测系统在（过）加载条件下的抖动/漂移包络）。不知道这将导致盲目

不可逆转的错误和不良做法，因为到目前为止所有累积的成本都已经被烧毁了......

知道

向美国宇航局阿波罗任务设计学习 - 它
分布广泛，适当的工程有助于到达月球
- 它拯救了民族自豪感和这些第一批，也是迄今为止唯一的Extra Terrestrians的生命
_{（归功于玛格丽特·汉密尔顿女士在定义她的设计规则方面的智慧，以及她改变了许多控制回路系统协调策略的正确工程的想法）}

ZeroMQ（zmq，是一种成熟的、可组合的、可扩展的、主要是分布式多对多行为的架构，是在一系列琐碎的可扩展正式通信模式原型的基础上开发的）或是Marting SUSTRIK的同父异母的妹妹，nanomsg，都可以帮助人们构建一个智能的宏系统，在这种情况下，单个组件的优势（或没有替代品的垄断）可能会相互连接到一个仍在等待时间阈值内的稳定的、具有优先级意识的宏系统中，原则上（或由于其他一些原因-成本经济性、上市时间、法律约束是首要因素-不想）为该系统设计一个整体一体的系统。

虽然乍一看，这听起来可能会使问题复杂化，但人们很快就会意识到，它确实起到了相反的作用：

• 在另一个重新发明的轮子上不烧燃料（是的，投资者的钱）
• 如果正确使用，使用经过行业验证的工具通常会提高可靠性…
• 性能扩展可能是一个很好的副作用，而不是一场为时已晚的噩梦

更不用说这些工具独立发展和它们的进一步扩展所带来的好处了。

我的系统也陷入了类似的困境- #C对我来说根本不是办法(对我们的成功来说，如果不是致命的，对封闭源代码应用程序的依赖也太昂贵了)。

< li>CLI:称为remote-keyboard是分离第一个python的确切例子，其中remote可以理解为跨大西洋键盘 < li>ML:是镇上最难控制的延迟元素，因此需要融合 < li>core-App:使用行业标准DLL扩展到分布式计算系统中，而不让it部门知道(只有剥离的核心逻辑保留在原位，其他都是分布式的，以便最小化所有控制循环的延迟，并允许处理不同级别的优先级) < li >非阻塞加载项:从核心应用中卸载 < Li > core-App-(1n)-Hot-stand-by-Shading:引入到最初的单片C/S exo-system中

这里是否需要添加更多的分布式和独立于原始供应商锁定？

选择了汗水、眼泪和鲜血——从ZeroMQ成熟的v2. x开始，我后悔没有一个小时这样做，也无法想象在没有这样做的情况下满足上述所有要求。