为 Twisted 中未维护的反应器做出贡献或维护单独的实现？
Contributing to unmaintained reactor in Twisted or maintain separate implementation?
未来编辑
从 twisted 15.5.0 和 kivy 1.9.1 开始，kivy 实现在 python3 上运行。我还使用 AMP，它尚未发布，但在 2 个月前合并，将在下一个扭曲版本中。
简介
我正在使用 Kivy 开发应用程序并计划使用多处理扩展它，更重要的是使用 Twisted。该应用程序有一个主组件和一个从属组件，应该可以从各种主机控制，包括通过网络（因此扭曲）。
Kivy 有它自己的扭曲支持代码（在 kivy/support.py 中称为 instal_twisted_reactor），它在 python2 中工作但在 python3 中不工作，因为未移植_threadedselect 反应器的状态。
我已经破解了 twisted/internet/_threadedselect.py 的端口到 python3 这足以 运行 kivy 示例代码（一个服务器 GUI 和一个客户端GUI 发送文本）。通常我会向上游请求拉取请求，但还有更多因素在起作用：-
据我所知，- _threadedselect.py 在 twisted 中没有得到维护，事实上最后一次在他们的邮件列表中提到是在 2006 年（作为删除的候选者）
- python3 移植的扭曲要求包括适当的单元测试，我不需要知识（尤其是网络方面的知识）来为这个反应器编写适当的单元测试
- 我不知道有没有其他项目（除了kivy）甚至使用_threadedselect.py
主要问题
鉴于上述情况，是否建议努力为上游打补丁 _treadedselect.py（并因此移植到 python3）？或者在我自己的项目中维护一个单独的实现会更有效（或者选择性地贡献给 kivy 的项目）。
免责声明：我（显然）不是这两个项目的维护者
非必要细节：
Kivy 不是 python 中最受欢迎的 UI 基地，因此它没有扭曲维护的反应堆（如 GTK、QT、TK 等），但它是最适合我想做的事。我考虑过龙卷风等，但这真的是另一个问题。
此外，（到目前为止）所需的修改非常小。 queue 到 Queue，zope 接口装饰器，除了使用 as 而不是逗号，以及使用函数 next 而不是使用生成器的 next 方法。
感谢您有兴趣为 Twisted 生态系统做出贡献。希望我能解开你的困惑，让你继续前进。
首先，Kivy 是一个非常重要的 Python 库，我们在 Twisted 项目中绝对关心它（我非常高兴听到您将它们一起使用！）所以您是如果你仅仅因为它 "isn't the most popular UI base in python" 就认为 Kivy 没有反应堆，那你就错了；它在 Twisted 中没有反应器的唯一原因是没有人贡献一个。
有几种可能的前进方式，但它们取决于您在问题中未涵盖的一些技术细节，一个 SO 答案可能不足以解决冲突；您可能想加入 Twisted mailing list 并在那里讨论这个问题。
不管 Python 3 端口如何，_threadedselect 都是私有的 API，没有兼容性契约，Kivy 不应该使用它。因此，为了向前迈进，这将需要改变。但是，它不太可能被删除，因为它是 wxpython 反应堆的内部基础， 是 一个 public API 分布扭曲了，最终需要移植到python3本身来完成移植。
前进的第一个方法是提高 _threadedselect 的测试覆盖率并使其再次成为 public API。这让我觉得这不一定是最好的举措，因为让线程交互正确是非常棘手的，我不想鼓励人们——即使是那些处理足够低级实现细节以想要实现反应器的人——那样做如果有任何其他选项可用。然而，如果 _threadedselect 在 Kivy 中有一个有效的用例，并且拥护者愿意做一些维护工作，这绝对是合理的。
第二种方法是在 Kivy 中创建一个基于内部套接字监控的反应器 API。有吗？ Kivy 封装的大多数 UI（CoreFoundation、X11、Windows）确实内置了某种套接字监控功能。Kivy 可以利用它吗？这比线程更不容易出错，如果你能管理的话，但有时这是不可能的；为此，我在 Kivy 中没有看到任何直接暴露的 APIs。如果你能开发这样的东西，它可以在 Twisted 或 Kivy 中，这取决于你的喜好。
我希望很快能在更注重讨论的论坛上收到您的来信:)
未来编辑
从 twisted 15.5.0 和 kivy 1.9.1 开始，kivy 实现在 python3 上运行。我还使用 AMP，它尚未发布，但在 2 个月前合并，将在下一个扭曲版本中。
简介
我正在使用 Kivy 开发应用程序并计划使用多处理扩展它，更重要的是使用 Twisted。该应用程序有一个主组件和一个从属组件，应该可以从各种主机控制，包括通过网络（因此扭曲）。
Kivy 有它自己的扭曲支持代码（在 kivy/support.py 中称为 instal_twisted_reactor），它在 python2 中工作但在 python3 中不工作，因为未移植_threadedselect 反应器的状态。
我已经破解了 twisted/internet/_threadedselect.py 的端口到 python3 这足以 运行 kivy 示例代码（一个服务器 GUI 和一个客户端GUI 发送文本）。通常我会向上游请求拉取请求，但还有更多因素在起作用：-
-
据我所知，
- _threadedselect.py 在 twisted 中没有得到维护，事实上最后一次在他们的邮件列表中提到是在 2006 年（作为删除的候选者）
- python3 移植的扭曲要求包括适当的单元测试，我不需要知识（尤其是网络方面的知识）来为这个反应器编写适当的单元测试
- 我不知道有没有其他项目（除了kivy）甚至使用_threadedselect.py
主要问题
鉴于上述情况，是否建议努力为上游打补丁 _treadedselect.py（并因此移植到 python3）？或者在我自己的项目中维护一个单独的实现会更有效（或者选择性地贡献给 kivy 的项目）。
免责声明：我（显然）不是这两个项目的维护者
非必要细节：
Kivy 不是 python 中最受欢迎的 UI 基地，因此它没有扭曲维护的反应堆（如 GTK、QT、TK 等），但它是最适合我想做的事。我考虑过龙卷风等，但这真的是另一个问题。
此外，（到目前为止）所需的修改非常小。 queue 到 Queue，zope 接口装饰器，除了使用 as 而不是逗号，以及使用函数 next 而不是使用生成器的 next 方法。
感谢您有兴趣为 Twisted 生态系统做出贡献。希望我能解开你的困惑，让你继续前进。
首先，Kivy 是一个非常重要的 Python 库，我们在 Twisted 项目中绝对关心它（我非常高兴听到您将它们一起使用！）所以您是如果你仅仅因为它 "isn't the most popular UI base in python" 就认为 Kivy 没有反应堆，那你就错了；它在 Twisted 中没有反应器的唯一原因是没有人贡献一个。
有几种可能的前进方式，但它们取决于您在问题中未涵盖的一些技术细节，一个 SO 答案可能不足以解决冲突；您可能想加入 Twisted mailing list 并在那里讨论这个问题。
不管 Python 3 端口如何，_threadedselect 都是私有的 API，没有兼容性契约，Kivy 不应该使用它。因此，为了向前迈进，这将需要改变。但是，它不太可能被删除，因为它是 wxpython 反应堆的内部基础， 是 一个 public API 分布扭曲了，最终需要移植到python3本身来完成移植。
前进的第一个方法是提高 _threadedselect 的测试覆盖率并使其再次成为 public API。这让我觉得这不一定是最好的举措，因为让线程交互正确是非常棘手的，我不想鼓励人们——即使是那些处理足够低级实现细节以想要实现反应器的人——那样做如果有任何其他选项可用。然而，如果 _threadedselect 在 Kivy 中有一个有效的用例，并且拥护者愿意做一些维护工作，这绝对是合理的。
第二种方法是在 Kivy 中创建一个基于内部套接字监控的反应器 API。有吗？ Kivy 封装的大多数 UI（CoreFoundation、X11、Windows）确实内置了某种套接字监控功能。Kivy 可以利用它吗？这比线程更不容易出错，如果你能管理的话，但有时这是不可能的；为此，我在 Kivy 中没有看到任何直接暴露的 APIs。如果你能开发这样的东西，它可以在 Twisted 或 Kivy 中，这取决于你的喜好。
我希望很快能在更注重讨论的论坛上收到您的来信:)