我开始学习一些Python,现在想玩一下GUI构建。qt似乎是一个不错的选择,因为它的跨平台性。现在似乎有两种绑定可用:Riverbank Computing的Pyqt和最初由诺基亚开发的Pyside。那么我应该选择哪一个呢?我所能找到的是两年前的特征比较,但是现在有什么区别呢?哪一个更容易使用,有更多/更好的文档?两者都还在积极发展吗?因为我不打算写商业应用程序,所以我不太关心许可问题。
- 我用Pyqt已经有一段时间了,对我来说,它看起来非常好。你应该考虑清楚你要用它做什么。如果你只说"窗口"和"按钮",我相信Pyqt绝对是个不错的选择。
- 这可能不算太多,但这种比较似乎是最新的:developer.qt.nokia.com/wiki/differences-between-pyside-u and-p‌&8203;yqt除了最大的区别可能是pyside还没有python 3支持,而p yqt已经有了它。
- 您还需要考虑Pyqt只附带了一个GPL许可证,但是Pyside更为宽容,并且是在lgpl下发布的。
- Pyside从1.0.8开始就支持python 3
这两个工具包都得到了积极的维护,到目前为止,在特性和质量上或多或少是平等的。只有很少的,相当不重要的差异。
不过,我还是推荐pyside用于python 2。它有一个更合理的API,主要是不公开qt类型,这些类型在python中有直接的等价物(如qstring、qlist等),或者由于python的动态特性(如qvariant)而完全多余。这样可以避免许多与qt类型之间的冗长转换,从而简化编程并避免许多错误。
Pyqt还支持这种现代API,并在默认情况下将其用于python 3,但不用于python 2以保持向后兼容性。
- 哦,天哪,那就更难了。因为我最近才开始学习python,所以我选择了使用python 3(正如python.org上建议的那样)。经过快速比较,诺基亚似乎提供了比河岸更好的文档(如@vort3x提供的文档)。
- @shutefan:对于我来说,几乎不使用带有pyqt和pyside的绑定文档。通常我阅读QT的优秀C++文档(它也有很好的例子,以及有关QT框架和技术的较长文章),并且只使用绑定文档查找Python特定的东西(如信号槽API)或被包装对象的签名。
- 在python 2上使用pyqt的api v1并不是真的。您可以使用sip.setapi轻松地将其切换到v2。riverbankcomputing.co.uk/static/docs/pyqt4/html/…
- @有点:我没有说任何不同的话,我只是说API v2在默认情况下没有为python 2启用。当然,它总是可以明确启用的(诚然,我应该这么说)。但是,如果您使用的库仍然需要api v1,这可能会导致问题,因为api v1和v2不能在同一个解释器中一起使用。
- @"我刚说过API v2默认情况下不支持python 2。"你在哪里说的?有人应该编辑和澄清。事实上,这个公认的答案实际上是误导性的。
- @Neuronet在最后一句话中说:"pyqt[…]支持这个现代API,并默认地将其用于python 3,但不用于python 2以保持向后兼容性。"注意"not"如何否定"default",从而得出明显的结论:在python 2上,默认值是api v1。你需要读我写的东西。
- @Lynaryorn足够公平,但它应该被编辑,因为它有点神秘(显式比隐式好),第二段是误导性的。两个人对你的回答感到困惑,读了你写的东西后,在这里的评论中说了些什么。可能应该在pyqt/python 2中添加如何执行此操作。当然,这会稍微破坏推荐Pyside超过Pyqt的原因(这是我发现的误导)。答案并不是很好地结合在一起。另外,在维修:v 4 v 5等中,Pyside接近Pyqt已经不再是真的了。
- pyside已经得到了qt:wiki.qt.io/qt-u for-python的官方支持。
还有许可证的区别。pyside是lgpl,而pyqt是gpl。如果您不想使您的项目成为开放源码的话,这可能会有所不同。尽管Pyqt总是以相当合理的价格提供适当的版本。
我倾向于发现Pyside文档更直观。在我看来,API更像是一种Python式的东西,而且目前的错误修复速度也相当惊人。
pyqt具有python 3支持和内省的优势。还有很多第三方文档/教程。
- 你给每位开发者打电话&163;350相当合理,是吗?当有一个项目在某个地方变得越来越好,而且越来越快,并且可以自由使用时,我不会这样做。您确实经常会遇到使用它的bug,但它们总是很快被修复。
- @克里斯摩根:那么你会说Pyside的开发更活跃?有人知道谁在Pyside后面吗?还是诺基亚吗?那样的话,我就不能太肯定这个项目的未来…
- @舒特凡:目前,派赛德在我看来更为活跃;它正在继续努力改善病情,而派克特4主要是跟上QT的进展。诺基亚以某种方式支持OpenBossa(我不知道具体安排),他们负责Pyside项目。我一直在想所有的qt东西会发生什么-qt,pyqt4,pyside,等等。-当诺基亚陷入困境(被收购)时,这似乎很快就会发生。我的答案是:我不知道;但在我看来,这些事情中的任何一件都不可能被他们的社区所允许。
- @Chrismorgan:刚刚查阅了OpenBossa,它似乎是由Nokia巴西直接资助的:web.openbossa.org/about the bazilian state似乎对他们的项目特别感兴趣,而且还是非常支持FOSS的,所以如果Nokia放弃支持,他们可能会加入。如果诺基亚将完全停止QT开发,KDE免费QT基金会将被允许在开源许可证下发布Qt:Web.OpenBasa.Org/
- @克里斯·摩根:是的。其他东西是可以得到的这一事实无关紧要。我知道写任何像pyqt和pyside这样有用的东西都需要比&163;350更长的时间。还请记住,对于某些人来说,LGPL是不可接受的,因此不是"免费的"。就未来而言,诺基亚正在年底(2011年)为Pyside筹集资金。我预计该项目将继续存在,但如果没有来自其他实体的现金注入,发展速度肯定会放缓。
- @杰拉尔德:是的,诺基亚正在停止为其提供资金,但在我看来,有关该项目未来的讨论方向是正确的,我怀疑它将由另一家实体赞助。LGPL有什么问题?我说,对于Pyqt4许可证,我不会认为&襛163;350是合理的,因为我认为Pyside总体上更好。
- @克里斯摩根,我认为LGPL没有问题。但我遇到过使用LGPL代码违反公司/客户策略的情况。我推测,这是由于与GPL和法律部门的联系做出了不知情的决定"站在安全的一边"。但是,它仍然意味着在这些实例中不能使用pyside。我想指出的是,就我个人而言,我只在项目中使用Pyside,因为它相当稳定。
- "如果你不想让你的项目成为开放源码的话,这可能会有所不同"。事实上,这是错误的,如果你的项目是非GPL的话,就有区别了。我正在开发一个开放源代码项目;BSD许可,而Pyqt对于这些场景来说过于严格,而且&163;350对于开放源代码项目来说是不可行的。
- 只是更新:Pyqt许可证现在是&163;390。
- 390是人类的大敌。
我最近将一个重要的代码库(超过8000行代码)从pyqt移植到了pyside。
现在我想说Pyqt是一个更成熟、性能更高、更稳定的项目。我在Pyside中发现了一些错误,并且怀疑任何大型项目都会遇到问题。说了这些之后,我向项目报告了一个bug,它在几周内就被修复了,并在一个新的版本中发布了。我也遇到了一个问题,这个应用程序需要大约15秒才能退出。我还没花时间找出原因。然而,选择Pyqt而不是Pyside只是时间问题。
如果您现在决定使用Pyqt,请确保始终使用API v2。它是一个更好的API,将来可以轻松过渡到Pyside。另外,如果您使用端口,只需遵循pyside wiki上的指南即可。即使是一个8+kloc的应用程序,包含大约20个源文件,也只花了一个下午。
- 自从我写了这个之后,Pyside项目已经垂死,但它仍然是一个不错的代码库。我的应用程序仍然运行良好,我击中的bug要么被修复,要么被琐碎的处理。我可能会在某个时候回到派克,但这样做并不紧迫。
- 皮赛德没有死……
- 关于Pyside和Qt5支持,似乎有一些好消息:wiki.qt.io/pyside-roudmap、lists.qt-project.org/pipermail/pyside/2015-april/002285.html和lists.qt-project.org/pipermail/pyside/2015-june/002298.html
虽然QT/C++类可能有类似的接口,但是它们对于QT/C++宏的接口,例如信号/时隙/属性是非常不同的。把一个移植到另一个并不容易。最好从一开始就做出正确的决定。
除了语法/许可证差异之外,我只想指出Pyqt在语言绑定方面的一些缺陷,这对于用Python编写QML项目可能是必不可少的。这些差异最终迫使我从派克脱口而出。
qMLReavestType
QML注册类型对于创建与QML的运行时C++绑定非常重要。在pyside中,它是pyside.qt声明性的一部分。这对python非常适用。
在Pyqt中,qmlRegisterType不存在。我也找不到其他方法。我知道通过设置qml上下文可以完成一些简单的任务。但是,如果您真的需要与qmlregister和q_可调用的运行时绑定,我认为pyside是目前唯一的选择。
石博肯与SIP
两者都可以将Qt/C++封装到Python插件中。对于Shiboken,我觉得它更简单,并且需要更少的编码。只需创建一个包含要导出的类的名称的类型系统XML,就可以了。Shiboken不需要对目标类的结构进行额外的手动描述。
对于SIP,它需要更多的额外编码。我们将不得不创建一个SIP文件,几乎重新实现所有的C++头。它不仅需要类的名称,还需要目标类具有哪些方法的详细信息。如果C++类使用PIMP进行了良好的设计,并且我们希望在其内部导出所有方法,SIP应该提供一种自动导出所有类方法的方法,这类方法目前无法。这也会增加维护SIP和C++头文件之间一致性的负担。
但我不得不说,Qtwiki上Shiboken的文档非常糟糕,误导了人们。在Windows上用Shiboken创建python插件并不一定需要cmake。也不需要GeneratorRunner。我只使用WindowsCmd脚本调用Shiboken,使用qmake pro编译目标插件。
- 有人知道目前的状况吗?Pyqt现在有运行时绑定了吗?你能把Pyqt和qml一起使用吗?没有任何障碍,Pyside也不会存在。
- 现在不再是这样了;Pyqt现在支持Pyqt5中的qmlRegisterType和qml绑定
一个重要的事实是,Pyqt4在某些方面有两个版本的API。版本1项是使用QString而不是unicode,和QVariant(基本上只是一个包装器,我相信-我从未真正做过任何使用它的事情)而不是包装。版本2可以在python 2中启用,在python 3中启用,它要好得多(尽管在许多地方仍然不太理想——pyside也一样,但是它明显更好了。它们还有一些不兼容的地方,Pyqt4有QtCore.pyqt(Signal|Slot|Property),Pyside有QtCore.(Signal|Slot|Property)。
对于我自己的一个项目,我决定在不更改代码的情况下支持两者。我更喜欢Pyside,但在Windows上,我用Pyqt4分发,目前它的分发规模要小得多。我的解决方案是检查PySide,如果有,插入一个导入钩子将Pyqt4导入重定向到PySide,或者如果没有,修复Pyqt4,使其正常工作。
使用的文件:
- pyqt4pysideimporter.py
- Zip-Imp.py(用于PY2Exe支持)
- make_gui.py(我的脚本,用于使用pyside或pyqt4工具生成.ui文件和.qrc文件,并将导入内容修复为一致;轮询文件更改并重新生成更改的内容-没有什么高科技能像inotify一样)
然后,您只需要import pyqt4pysideimporter和pyqt4pysideimporter.autoselect()(如该存储库中的main.py)。在那之后,你就可以开始了。
旁白:几天前Pyside邮件列表中也提到,他们计划在未来几个月内完全支持Python3。
- 你说它在Windows上比较小,其他平台又有多少呢?
- @shutefan:当所有的代码都以最佳方式出现时(见make_py2exe.py——一组Py2Exe Plus压缩upx的最佳标志),我认为两者之间的区别是8MB而不是9-10MB(也就是说,包括完整的python运行时和我所有的东西),但我记不清具体的数字。在Linux上,表示python模块的.so文件的大小平均是pyqt4模块的两倍左右。
我有一个20K行的python应用程序,但我没有成功地将其转换为pyside。转换很容易,而且大部分功能都可以工作。有几个方法没有实现,因为它们是"弃用的",所以我必须修复它们。没关系。在Windows上,使用pyside-1.1.2,没有为许多qt对象实现"=="运算符。一个解决方法是说:"if id(item1)==id(item2):"。另一个观察是Pyside似乎明显慢了。我并没有将Pyside孤立为导致速度缓慢的原因,但当我恢复到Pyqt时问题就消失了。
最后,到目前为止,带有Pyside的Android套件似乎还没有准备好迎接黄金时间。
- 似乎选择是使用.NET(Pyqt)还是Delphi(Pyside),这实际上是安全的,可以说Pyqt总是比Pyside领先一步。