首先：我是 Qt 和 SWIG 的新手。目前正在阅读这两者的文档，但这是一项耗时的任务，所以我正在寻找一些剧透。预先知道某事是否行不通是件好事。
我正在尝试为一些内部软件制定模块化架构。核心组件使用 C++，并通过 SWIG 暴露给 Python，用于新组件的实验和快速原型设计。 Qt 似乎有一些类可以用来避免在这里过多地重新发明轮子，但我担心其中一些位如何组合在一起。
具体来说，如果我创建一些 C++ 类，我需要通过 SWIG 公开它们。其中一些类可能是 Qt 类的子类，或者在其公共接口中公开了 Qt 内容。这似乎会引发一些并发症。
Qt 在 Python 中已经有两个接口，PyQt 和 PySide。出于许可原因，可能会使用 PySide。我应该期望得到一个 Qt 类的 SWIG 包装的自定义子类来与这些中的任何一个一起玩得有多痛苦？我应该预先了解哪些并发症？
【问题讨论】：
PyQt 通过SIP 向 Python 公开 C++ 代码； PySide 通过Shiboken 进行操作。两者都具有与 SWIG 大致相同的功能（除了它们仅支持“将 C++ 扩展为 Python”，而 SWIG 还具有 Ruby、Perl、Java 等的后端）。 SWIG 和 SIP 和 Shiboken 均未设计为可相互操作。您不能方便地使用 SWIG 使用 Qt 所需的 C++ 扩展来包装任何代码（以支持信号和插槽），而且我不知道在尝试互操作 SIP 包装（或 Shiboken 包装）和 SWIG 时可能会遇到什么危险- 包装代码。
请问，您为什么选择使用两种独立且等效的方式来包装您的 C++ 代码库的不同部分（Qt 通过 SIP 或 Shiboken，其他一切都通过 SWIG）？如果您仍然可以重新考虑这个奇怪的设计决定，我会真诚地建议您这样做。
如果您对 SWIG 的选择是一成不变的，那么我预测您在使用 Qt 扩展（即插槽或信号）封装 C++ 代码时会遇到很大的麻烦，并且对于所有相关人员来说通常会非常痛苦。如果你选择一种方式来包装，并坚持下去，问题应该会大大减少。我没有使用 Shiboken 的实际经验（它有点太新了，而且这些天我几乎不再使用 GUI 应用程序了......我的世界都是网络应用程序！-），但过去曾在这个角色中使用过 SIP（早在它被体面地记录之前——这些天在我看来，它的记录精彩，而且对 Shiboken 的肤浅阅读给了我同样的印象）我可以高度推荐它（如果我可以选择的话即使项目中不涉及 Qt 代码，它也可能比 SWIG 更可取）。
【讨论】：