Both toolkits are actively maintained, and by now more or less equal in features and quality. There are only few, rather unimportant differences.
Still, I'd recommend PySide for Python 2. It has a more reasonable API, mainly it doesn't expose Qt types, which have a direct equivalent in Python (e.g. QString, QList, etc.) or which are completely superfluous due to Python's dynamic nature, like QVariant. This avoids many tedious conversions to and from Qt types, and thus eases programming and avoids many errors.
PyQt also supports this modern API, and uses it by default for Python 3, but not for Python 2 to maintain backwards compatibility.
There is also the licensing difference. PySide is LGPL while PyQt is GPL. This could make a difference if you don't wish to make your project opensource. Although PyQt always has the propriety version available for a fairly reasonable price.
I tend to find the PySide documentation more intuitive. The API, in my opinion is slightly more Pythonic and the rate of bug fixes is quite impressive at the moment.
PyQt has the advantage of Python 3 support and incumbency. There is a lot more 3rd party documentation/tutorials for it.
如果您现在决定使用 PyQt，请确保自始至终都使用 API v2。它是一个更好的 API，并将简化未来向 PySide 的过渡。另外，如果您进行移植，只需遵循 PySide wiki 上的指南即可。即使对于一个由大约 20 个源文件组成的 8+ kloc 应用程序，也只花了一个下午的时间。
I recently ported a significant code base (over 8,000 lines of code) from PyQt to PySide.
Right now I'd say PyQt is a much more mature, performant and stable project. I hit a number of bugs in PySide, and suspect that any big project will hit issues. Having said that, I reported a bug to the project and it was fixed and in a new release within a few weeks. I'm also having a problem where the app takes about 15 seconds to quit. I've not yet spent the time to find out why. However it's only a matter of time before there will be no reasons for choosing PyQt over PySide.
If you do decide to go with PyQt for now, make sure you use API v2 throughout. It is a better API, and will ease any future transition to PySide. Also if you do port, just follow the guidelines on the PySide wiki. Even for an 8+ kloc app consisting of about 20 source files it just took an afternoon.
对于 SIP，需要更多额外的编码。我们必须创建一个几乎重新实现 C++ 头的所有内容的 SIP 文件。 它不仅需要类的名称，还需要目标类具有的方法的详细信息。 如果 C++ 类使用 Pimp 进行了良好的设计，并且我们想要导出其中的所有方法，那么 SIP 应该提供一种自动导出所有类方法的方法，但目前还不能。 这也会增加维护 SIP 和 C++ 标头之间一致性的负担。
但我不得不说 Qt wiki 上的 Shiboken 文档非常糟糕且具有误导性。 在 Windows 上使用 Shiboken 创建 Python 插件根本不需要 CMake。 generatorrunner 也不是必需的。 我只使用Windows cmd脚本来调用shiboken，并使用qmake pro来编译目标插件。
Although they might have similar interface for Qt/C++ classes, their interface for Qt/C++ macros such as signal/slot/property are very different. Porting one to another is not an easy job. It would be better to make the right decision at the very beginning.
Beyond the grammar/license differences, I just want to point out some deficiency of PyQt in language binding, which might be essential to write QML project in Python. These differences finfally push me to PySide from PyQt.
qmlRegisterType
qmlRegisterType is essential to create runtime C++ binding with QML. In PySide, it is part of PySide.QtDeclarative. And this works pretty well with Python.
In PyQt, qmlRegisterType does not exist. And I could not find an alternative approach. I know some simple task could be done by setting QML context. But if you really need runtime binding with qmlRegister and Q_INVOKABLE, I think PySide is the only choice at the moment.
Shiboken VS SIP
Both can wrap Qt/C++ into python plugin. For Shiboken, I feel it is simpler and requires less coding. Just create a typesystem xml including the NAME of classes you want to export, and that's all. Shiboken does not require extra manual descriptions for the structure of the target classes.
For SIP, it would require more extra coding. We will have to create a SIP file that almost reimplements everything the C++ header. It requires not only the NAME of the class, but also the DETAILS of what methods the target classes have. If the C++ class is in good design using Pimp and we want to export all methods within it, SIP should provide a way of automatically export all class methods, which it cannot at the moment. This would also add the burden for maintaining the consistency between the SIP and the C++ headers.
But I have to say that the documentation for Shiboken on Qt wiki is very bad and misleading. Creating Python plugin with Shiboken on Windows do not necessarily require CMake at all. generatorrunner is also not required. I only use a windows cmd script to invoke shiboken, and a qmake pro for compiling the target plugin.
An important fact is that PyQt4 has two versions of its APIs for some things. Version 1 items are such things as using QString instead of unicode, and QVariant (basically just a wrapper, I believe - I've never actually done anything which uses it) instead the wrapped. Version 2, which can be enabled in Python 2 and is enabled in Python 3, is much better (though still unpythonic in many places - PySide is too, but it's getting distinctly better. There are still some remaining incompatibilities with them; PyQt4 has QtCore.pyqt(Signal|Slot|Property), PySide has QtCore.(Signal|Slot|Property).
For a project of my own, I decided that I wanted to support both with no changes to the code. I prefer PySide, but on Windows I distribute with PyQt4 as at present it's quite a bit smaller for distribution at present. My solution is to check for PySide and if it's there insert an import hook to redirect PyQt4 imports to PySide, or if it's not, fix up PyQt4 to work like it should.
make_gui.py (my script for building .ui files and .qrc files with pyside or pyqt4 tools, and fixing the imports to be consistent; polls for file changes and rebuilds the changed - nothing high tech like inotify)
Then you just import pyqt4pysideimporter and pyqt4pysideimporter.autoselect() (as in main.py in that repository). And after that you can just import PyQt4.
Aside: it was also stated a few days ago on the PySide mailing list that they are planning on supporting Python 3 fully within the next few months.
I have a 20k line Python app that I unsuccessfully tried to convert to PySide. Conversion is easy and most of the functionality works. There are several methods that are not implemented because they are 'deprecated', so I had to fix those. That was OK. On Windows, using PySide-1.1.2, the '==' operator is not implemented for many Qt objects. One workaround is to say: "if id(item1) == id(item2):". The other observation is that PySide seemed noticeably slower. I did not isolate PySide as the cause of the slowness, but the problem went away when I reverted back to PyQt.
Lastly, as of now, the Android kit with PySide does not seem ready for prime time.
发布评论
评论（6）
这两个工具包都得到积极维护，到目前为止在功能和质量上或多或少相同。只有很少的、相当不重要的差异。
不过，我还是推荐 Python 2 的 PySide。它有一个更合理的 API，主要是它不公开 Qt 类型，而 Qt 类型在 Python 中有直接等效项（例如 QString、QList 等），或者由于以下原因而完全多余Python 的动态特性，就像 QVariant 一样。这避免了许多繁琐的 Qt 类型转换，从而简化了编程并避免了许多错误。
PyQt 也支持这种现代 API，并默认将其用于 Python 3，但不用于 Python 2 以保持向后兼容性。
Both toolkits are actively maintained, and by now more or less equal in features and quality. There are only few, rather unimportant differences.
Still, I'd recommend PySide for Python 2. It has a more reasonable API, mainly it doesn't expose Qt types, which have a direct equivalent in Python (e.g. QString, QList, etc.) or which are completely superfluous due to Python's dynamic nature, like QVariant. This avoids many tedious conversions to and from Qt types, and thus eases programming and avoids many errors.
PyQt also supports this modern API, and uses it by default for Python 3, but not for Python 2 to maintain backwards compatibility.
还有许可方面的差异。 PySide 是 LGPL，而 PyQt 是 GPL。如果您不希望将项目开源，这可能会有所不同。尽管 PyQt 始终以相当合理的价格提供专有版本。
我倾向于发现 PySide 文档更直观。在我看来，API 更加 Pythonic 一些，而且目前错误修复的速度相当令人印象深刻。
PyQt 具有 Python 3 支持和现有的优势。还有更多的第三方文档/教程。
There is also the licensing difference. PySide is LGPL while PyQt is GPL. This could make a difference if you don't wish to make your project opensource. Although PyQt always has the propriety version available for a fairly reasonable price.
I tend to find the PySide documentation more intuitive. The API, in my opinion is slightly more Pythonic and the rate of bug fixes is quite impressive at the moment.
PyQt has the advantage of Python 3 support and incumbency. There is a lot more 3rd party documentation/tutorials for it.
我最近将重要的代码库（超过 8,000 行代码）从 PyQt 移植到 PySide。
现在我想说 PyQt 是一个更加成熟、高性能和稳定的项目。我在 PySide 中遇到了许多错误，并怀疑任何大型项目都会遇到问题。话虽如此，我向该项目报告了一个错误，该错误在几周内得到了修复并在新版本中发布。我还遇到一个问题，应用程序需要大约 15 秒才能退出。我还没有花时间找出原因。然而，没有理由选择 PyQt 而不是 PySide 只是时间问题。
如果您现在决定使用 PyQt，请确保自始至终都使用 API v2。它是一个更好的 API，并将简化未来向 PySide 的过渡。另外，如果您进行移植，只需遵循 PySide wiki 上的指南即可。即使对于一个由大约 20 个源文件组成的 8+ kloc 应用程序，也只花了一个下午的时间。
I recently ported a significant code base (over 8,000 lines of code) from PyQt to PySide.
Right now I'd say PyQt is a much more mature, performant and stable project. I hit a number of bugs in PySide, and suspect that any big project will hit issues. Having said that, I reported a bug to the project and it was fixed and in a new release within a few weeks. I'm also having a problem where the app takes about 15 seconds to quit. I've not yet spent the time to find out why. However it's only a matter of time before there will be no reasons for choosing PyQt over PySide.
If you do decide to go with PyQt for now, make sure you use API v2 throughout. It is a better API, and will ease any future transition to PySide. Also if you do port, just follow the guidelines on the PySide wiki. Even for an 8+ kloc app consisting of about 20 source files it just took an afternoon.
尽管它们可能具有类似的 Qt/C++ 类接口，但它们的 Qt/C++ 宏（例如信号/槽/属性）接口却非常不同。
将一个移植到另一个并不是一件容易的事。最好在一开始就做出正确的决定。
除了语法/许可差异之外，我只想指出 PyQt 在语言绑定方面的一些缺陷，这对于用 Python 编写 QML 项目可能至关重要。
这些差异最终将我从 PyQt 推向了 PySide。
qmlRegisterType
qmlRegisterType 对于创建与 QML 的运行时 C++ 绑定至关重要。
在 PySide 中，它是 PySide.QtDeclarative 的一部分。这与 Python 配合得很好。
在 PyQt 中，qmlRegisterType 不存在。我找不到替代方法。
我知道可以通过设置 QML 上下文来完成一些简单的任务。
但如果您确实需要与 qmlRegister 和 Q_INVOKABLE 进行运行时绑定，我认为 PySide 是目前唯一的选择。
Shiboken VS SIP
两者都可以将 Qt/C++ 封装成 python 插件。
对于Shiboken，我觉得它更简单并且需要更少的代码。
只需创建一个类型系统 xml，其中包含要导出的类的名称，仅此而已。
Shiboken不需要对目标类的结构进行额外的手动描述。
对于 SIP，需要更多额外的编码。我们必须创建一个几乎重新实现 C++ 头的所有内容的 SIP 文件。
它不仅需要类的名称，还需要目标类具有的方法的详细信息。
如果 C++ 类使用 Pimp 进行了良好的设计，并且我们想要导出其中的所有方法，那么 SIP 应该提供一种自动导出所有类方法的方法，但目前还不能。
这也会增加维护 SIP 和 C++ 标头之间一致性的负担。
但我不得不说 Qt wiki 上的 Shiboken 文档非常糟糕且具有误导性。
在 Windows 上使用 Shiboken 创建 Python 插件根本不需要 CMake。
generatorrunner 也不是必需的。
我只使用Windows cmd脚本来调用shiboken，并使用qmake pro来编译目标插件。
Although they might have similar interface for Qt/C++ classes, their interface for Qt/C++ macros such as signal/slot/property are very different.
Porting one to another is not an easy job. It would be better to make the right decision at the very beginning.
Beyond the grammar/license differences, I just want to point out some deficiency of PyQt in language binding, which might be essential to write QML project in Python.
These differences finfally push me to PySide from PyQt.
qmlRegisterType
qmlRegisterType is essential to create runtime C++ binding with QML.
In PySide, it is part of PySide.QtDeclarative. And this works pretty well with Python.
In PyQt, qmlRegisterType does not exist. And I could not find an alternative approach.
I know some simple task could be done by setting QML context.
But if you really need runtime binding with qmlRegister and Q_INVOKABLE, I think PySide is the only choice at the moment.
Shiboken VS SIP
Both can wrap Qt/C++ into python plugin.
For Shiboken, I feel it is simpler and requires less coding.
Just create a typesystem xml including the NAME of classes you want to export, and that's all.
Shiboken does not require extra manual descriptions for the structure of the target classes.
For SIP, it would require more extra coding. We will have to create a SIP file that almost reimplements everything the C++ header.
It requires not only the NAME of the class, but also the DETAILS of what methods the target classes have.
If the C++ class is in good design using Pimp and we want to export all methods within it, SIP should provide a way of automatically export all class methods, which it cannot at the moment.
This would also add the burden for maintaining the consistency between the SIP and the C++ headers.
But I have to say that the documentation for Shiboken on Qt wiki is very bad and misleading.
Creating Python plugin with Shiboken on Windows do not necessarily require CMake at all.
generatorrunner is also not required.
I only use a windows cmd script to invoke shiboken, and a qmake pro for compiling the target plugin.
一个重要的事实是，PyQt4 对于某些功能有两个版本的 API。版本 1 的项目是使用
QString而不是unicode和QVariant（基本上只是一个包装器，我相信 - 我从来没有真正做了任何使用它的事情）而不是包装的。版本 2 可以在 Python 2 中启用，也可以在 Python 3 中启用，它要好得多（尽管在很多地方仍然不符合 Python 标准——PySide 也是如此，但它明显变得更好了。仍然存在一些与它们不兼容的地方；PyQt4 有 <代码>QtCore.pyqt(Signal|Slot|Property)，PySide有QtCore.(Signal|Slot|Property)。对于我自己的项目，我决定在不更改代码的情况下支持两者，但在 Windows 上我使用 PyQt4 进行分发，因为目前它的分发规模要小一些。检查 PySide，如果有，则插入一个导入钩子以将 PyQt4 导入重定向到 PySide，或者如果没有，请修复 PyQt4 以使其正常工作
使用的文件：
然后您只需
import pyqt4pysideimporter和pyqt4pysideimporter.autoselect()（如main.py< /code> 在该存储库中）。之后您只需导入 PyQt4即可。另外：几天前 PySide 邮件列表上还表示，他们计划在未来几个月内完全支持 Python 3。
An important fact is that PyQt4 has two versions of its APIs for some things. Version 1 items are such things as using
QStringinstead ofunicode, andQVariant(basically just a wrapper, I believe - I've never actually done anything which uses it) instead the wrapped. Version 2, which can be enabled in Python 2 and is enabled in Python 3, is much better (though still unpythonic in many places - PySide is too, but it's getting distinctly better. There are still some remaining incompatibilities with them; PyQt4 hasQtCore.pyqt(Signal|Slot|Property), PySide hasQtCore.(Signal|Slot|Property).For a project of my own, I decided that I wanted to support both with no changes to the code. I prefer PySide, but on Windows I distribute with PyQt4 as at present it's quite a bit smaller for distribution at present. My solution is to check for PySide and if it's there insert an import hook to redirect PyQt4 imports to PySide, or if it's not, fix up PyQt4 to work like it should.
The files used:
Then you just
import pyqt4pysideimporterandpyqt4pysideimporter.autoselect()(as inmain.pyin that repository). And after that you can justimport PyQt4.Aside: it was also stated a few days ago on the PySide mailing list that they are planning on supporting Python 3 fully within the next few months.
我有一个 20k 行的 Python 应用程序，但尝试将其转换为 PySide 失败。
转换很容易并且大多数功能都可以使用。
有几种方法没有实现，因为它们已被“弃用”，所以我必须修复这些方法。没关系。
在 Windows 上，使用 PySide-1.1.2，许多 Qt 对象未实现“==”运算符。一种解决方法是：“if id(item1) == id(item2):”。
另一个观察结果是 PySide 似乎明显慢一些。我没有将 PySide 视为缓慢的原因，但当我恢复到 PyQt 时问题就消失了。
最后，截至目前，带有 PySide 的 Android 套件似乎还没有准备好迎接黄金时段。
I have a 20k line Python app that I unsuccessfully tried to convert to PySide.
Conversion is easy and most of the functionality works.
There are several methods that are not implemented because they are 'deprecated', so I had to fix those. That was OK.
On Windows, using PySide-1.1.2, the '==' operator is not implemented for many Qt objects. One workaround is to say: "if id(item1) == id(item2):".
The other observation is that PySide seemed noticeably slower. I did not isolate PySide as the cause of the slowness, but the problem went away when I reverted back to PyQt.
Lastly, as of now, the Android kit with PySide does not seem ready for prime time.