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

Posted 2023-03-31

【中文标题】如何使用 python .Net vs ZeroMQ 或其他方法将 Python 包公开给 C#

【英文标题】：How to expose a Python package to C# using python .Net vs ZeroMQ or other

【发布时间】：2020-05-05 06:58:31

【问题描述】：

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

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

我对如何做到这一点进行了大量研究，并提出了一些潜在的解决方案。

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

请注意，我不精通 C#，将在 linux 中进行大部分开发。

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

【问题讨论】：

Given (cit.) ：“……我担心延迟，因为……这个工具用于硬件控制。” - 什么是延迟上限 [我们] 您的系统控制回路已设计为其稳定性阈值？

由于一种极端情况，我的延迟上限约为 10 毫秒。通常为 100 毫秒。

我不确定应用程序到底是什么，但延迟要求如此之低，您是否考虑过根本不使用 python？由于涉及硬件，您可能可以在 C 中与它进行交互，并且 C 很容易与 C# 集成。

嗯，这实际上是在替换以前用 C 实现的东西。这个想法是，如果库的接口层和 cli 用 Python 实现，那么用户会更容易构建核心他们的用例的功能。一些要求更高的控制循环可能必须实现为静态 C 库或 rust 库，我们将使用 python 调用它们。无论如何，顶层仍然是用 Python 实现的，它必须与 C# 接口

【参考方案1】：

目标：~ 10 [ms] 下的延迟对于SuT-稳定性？

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

...这实际上是替换以前在 C 中实现的东西。想法是，如果库的 接口层 和 cli 是在 Python 中实现的，因此用户更容易为他们的用例构建核心功能。一些要求更高的控制循环可能必须实现为静态 C 库或 rust 库，我们将使用 python 调用它们。在任何情况下，顶层仍然是用 Python 实现的，它必须与 C# 接口_{（=这里最重要的收获 …需要了解希望轻松进行用户扩展和重构架构的成本+谁支付这些费用)}

---

在我们开始搜索解决方案之前：

为了安全和专业地完成这项工作，您很可能会喜欢this，而不是重复不知情决策的常见错误，其中一般性评论来自大量制作具有控制的系统的第一手经验-在~ 80 [us]下循环

映射您的控制系统 - 内部生态系统_（资源）和外部系统 _{（与外部世界的互动）}

接下来是架构：

如果没有对玩具有适当的了解，没有人可以决定 The Right-enough Architecture。

了解latency-motivated device 中的设备情况需要我们首先知道（读取 + 测试 + 基准测试以及它在 S （过载）条件下的抖动/漂移包络系统-under-Test）。不知道这会导致盲目和事实不受支持的信念，我们的 SuT 永远不会撞到 the wall of reality，这通常会在最不愉快的时刻证明自己是错误的。

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

了解和测试是在勾画架构之前的核心步骤 - 细节很重要（ref.h2d/d2h 延迟有多少[us]? - 为什么这些本金成本的报告如此薄弱？这是否意味着这些成本不存在？不。它们确实存在，并且您的控制回路会每次都支付它们......所以更好地了解所有这些隐藏成本，支付在 TimeDOMAIN 中，提前...before Architecture 被设计和起草。）

---

不要犹豫去分布式_{（合理supported）}：

向美国宇航局阿波罗任务设计学习- 它分布很广并且- 适当的工程有助于到达月球- 它拯救了民族自豪感和这些第一批人的生命，并且迄今为止唯一的，Extra Terrestrians_{（归功于Ms.Margaret HAMILTON 的智慧在定义她的设计规则和她改变了许多控制的适当工程的想法-loops-systems 的协调策略 )}

ZeroMQ（zmq，是一个成熟的、可组合的、良好的扩展性、主要分布式多对多的架构behaviours，是在一组Trivial Scalable之上开发的正式沟通模式原型）或者它是马丁 SUSTRIK 共同父亲的年轻轻量级妹妹nanomsg，可能有助于构建一个智能宏观系统，其中单个组件的优势（或无可替代的垄断）可能连接到一个仍然在延迟阈值内的stable, priority-aware macro-system，原则上不能（或不希望，由于其他一些原因——成本经济、上市时间、法律限制是第一个手头的）设计一个单一的一体化系统。

乍一看，这听起来可能使问题复杂化，但很快就会意识到，它的作用恰恰相反：

在另一个

重新发明***

（s…）上不燃烧燃料（是的，投资者的钱） 最常使用经过行业验证的工具

提高可靠性

，当然，如果使用得当……

性能扩展

可能是一个很好的副作用，而不是恐慌为时已晚而无法重构噩梦

更不用说此类工具独立发展及其进一步扩展所带来的积极好处。

我的系统也陷入了类似的困境——#C 暂时不适合我（闭源应用程序依赖对于我们的成功来说即使不是致命的，也太昂贵了）。

CLI：

称为 remote-keyboard 是拆分第一个 python 的确切示例，其中 remote 可以被读取为

trans-atlantic em>

-键盘

ML：

是镇上控制最少的延迟元素，因此需要融合 core-

App:

使用行业标准 DLL 扩展为

distributed-computing

系统，但不让它知道（只有剥离的 core-逻辑保持在原位，其他一切都分散了，以便最大限度地减少所有控制回路的延迟并让处理不同级别的优先级）

非阻塞加载项

：从核心应用中卸载 core-App-

(1+N)-Hot-Standby

-Shading：被引入一个原本单片的 C/S exo-system

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

选择了汗水、泪水和鲜血——从 ZeroMQ 在成熟的 v2.x 时代开始，我后悔没有这样做，无法想象会遇到以上所有情况没有这样做。

【讨论】：

这似乎是最有吸引力的选择之一。在创建 dll 原型进行了一些工作之后，它似乎有其自身的缺点（与采用更分布式的路线相比）必须维护 dll 及其发布过程的额外成本。我唯一的问题是选择 zeromq 而不是更轻量级的 nanomsg，或者像 [gRPC][1] 或 [Thrift][2] 这样的代码生成（与语言无关）有什么价值？ [1]：grpc.io/docs/tutorials/basic/python [2]：thrift-tutorial.readthedocs.io/en/latest/usage-example.html

*** 强烈劝阻不要通过 cmets 爬行主题，进入新的方向和/或新的问题。随意打开另一个新问题，发布新的上下文和任何新的观点，这可能已经从以前的 Q/A-s 中散布出来了。这是既公平又符合社区网络礼仪的步骤，不是吗？

很公平，原始问题的一部分是在 zeromq 与 gRPC 但是如果您认为最好在其自己的问题中进行探索，如果研究失败，我可以这样做。

【参考方案2】：

您说您的 python 应用程序有一个 cli，因此另一个可能的选择是让您的 C# 应用程序通过命令行与您的 python 应用程序交互。

您需要通过命令行参数公开 Python 功能（无论如何您可能已经这样做了），并且您的 Python 应用程序需要能够将结果作为 json 数据返回，这可能是使用它的最简单方法C#。

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

【讨论】：

这不会比上述选项慢很多吗？