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

Question

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

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

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

1. 使用Python.Net在C＃应用程序中实现Python脚本，该脚本导入我的python包并调用所需的方法/属性。我还无法自己在Monodevelop上进行此工作，但这似乎是一个受欢迎的选择，尽管关于我的用例没有太多文档。
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 [ms]下的SuT稳定性等待时间？

感谢您提供有关相当广泛的延迟上限_{~ 10 .. 100 [ms]}

+的详细信息

…这实际上是replacing

，以前是用C实现的。这个想法是，如果库的interface layer和cli是用Python实现的， 更易于用户使用为其使用案例构建核心功能。一些要求较高的控制循环可能必须实现为静态C库或rust库，我们将使用python调用它。无论如何，顶层仍然是在Python中实现的，它将必须与C＃进行接口 （_{=这里最重要的要点 ...需要了解两者The Costs}易于实现的用户扩展和重构体系结构+ Who] pays这些Costs]

---

甚至在我们开始搜索

The Solution：之前为了安全而专业地进行此操作，您很可能会喜欢this，不要重复未作出明智决定的常见错误，其中的一般性评论源于大量的手工制作经验

具有控制回路的系统在~ 80 [us]

下

Map

您控制系统的-内部都是[[eco-system （资源）＆exo-system _{（与外部世界的交互）}接下来是体系结构：

没有对玩具的适当了解，没有人可以决定合适的建筑。

[了解latency-motivated device中设备的情况要求我们首先知道（读取+测试+基准测试，也就是

S

ystem-

的（过载）条件下的抖动/漂移包络）。 u

nder-T est）。不知道这会导致盲目的事实支持，我们的SuT将永远不会陷入the wall of reality，这通常会在最不愉快的时刻证明自己是错误的。严重错误和不当做法，因为到目前为止所有应计费用都已被烧掉...了解和测试是构建架构的核心步骤

之前

-细节很重要（

ref. h2d/d2h延迟[us]中有多少是宽松的？

-这些主要成本为何​​如此报告不力吗？难道这些成本不存在？不。它们确实存在，您的控制回路每次都将支付'......因此更好地了解所有此类隐性成本，均以TimeDOMAIN ，提前... before Architecture得到设计和起草。）不要犹豫去分发

---

（在合理的情况下supported]：

[从NASA阿波罗任务设计中学习-分布广泛，并且-适当的工程技术帮助到达月球-它既挽救了民族自豪感，也拯救了第一批也是迄今为止唯一的Extra Terrestrians的生命（（[ Ms.Margaret HAMILTON的

智慧

定义她的设计规则，并改变了许多控制回路系统的协调策略的正确工程思路[]]_{E [ZeroMQ（zmq，是一种成熟的，可组合的，可扩展的，主要分布于多对多[[behaviours}的体系结构]，它是在一些普通的可伸缩形式化通信模式原型的集合上开发的），或者是Marting SUSTRIK共同生的年轻且轻便的姐妹nanomsg，可能会帮助一个人组成一个智能的宏观系统，在这个系统中，各个组件的优势（或无可替代的垄断）可能会相互关联。仍然处于等待时间阈值nanomsg，对于该阈值来说，原则上不能（或者由于其他一些原因而不想这样做-成本节约，上市时间，法律约束是第一手的阈值）设计一个整体式[[all-in-one系统。虽然乍一看这听起来像是使问题复杂化，但很快就会意识到，它确实正好相反：

不燃烧燃料（是的，投资者的钱）是另一个重新发明轮子

（s…）

最经常使用经过行业验证的工具

提高可靠性

，如果使用的是对，请确保…

性能扩展可能会带来很好的副作用，而不是panic

为时已晚，无法重构

噩梦没有提及这种工具独立发展及其进一步扩展所带来的积极收益。

我的系统处在类似的困境中-#C并不是我的方法（封闭源应用程序依赖项对于我们的成功不是致命的，但代价太高）。CLI：称为

remote-keyboard

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

trans-atlantic

-keyboard

ML：是该镇中受控制最少的延迟元素，因此需要融合]

使用行业标准的DLL将core-App：扩展到stable, priority-aware macro-system系统中，而没有让它知道（只有剥离的核心逻辑保持原位，所有否则将其分发，以最大程度地减少所有控制循环的延迟，并让它们处理不同级别的优先级）

非阻塞性附件：已从核心应用程序卸载

core-App-（（1 + N）-Hot-Standby-阴影：引入到原始的整体C / S exo系统中]

这里是否需要添加更多内容以使其更加分散并且独立于原始的供应商锁定？

虽然选择了汗水，眼泪和鲜血-从ZeroMQ在成熟的v2.x时代开始，我很遗憾没有一个小时这样做过，>并且无法想象满足以上所有条件。