ChatGPT解决这个技术问题 Extra ChatGPT

PyQt or PySide - which one to use [closed]

Closed. This question is opinion-based. It is not currently accepting answers. Want to improve this question? Update the question so it can be answered with facts and citations by editing this post. Closed 8 years ago. Improve this question

I started learning a bit of python and would now like to toy around a bit with gui-building. Qt seems to be a good choice because of its cross-platformishness. Now there seem to be two bindings available: PyQt by Riverbank Computing and PySide, originally developed by Nokia. So which one should I choose? All I can find are two year old feature comparisons, but what differences are there nowadays? Which one is easier to use, has more/better documentation? Are both still in active development? Licensing isn't of much concern to me since I don't intend to write commercial applications.

I've been using PyQt for a while and for me it seemed to be absolutely fine. You should consider clarifying what you're going to do with it. If you're only speaking about "windows" and "buttons", I believe PyQt is absolutely good choice.
It may not be much - but this comparison seems fairly up-to-date: developer.qt.nokia.com/wiki/Differences_Between_PySide_and_PyQt Apart from that the biggest difference is probably that pyside does not yet have python 3 support, whereas pyqt does have it already.
You also need to consider that PyQt comes only with a GPL license, but pyside is more permissive and is released under LGPL.
PySide has support python 3 since 1.0.8

佚名

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.


Oh my, that makes it even harder. Since I just very recently started to learn python I chose to go for python 3 (as is advised on python.org). After a quick comparison it seems that Nokia offers better documentation (as provided by @Vort3x) than Riverbank...
@shutefan: I for my part only scarcely use the documentation for the bindings, with PyQt as well as PySide. Commonly I read the outstanding C++ documentation for Qt (it also has quite good examples, and longer articles about Qt frameworks and techniques), and only use the binding documentation to look up Python specific things (like the signal-slot API) or signatures of wrapped objects.
It is not true that you have to use PyQt's API v1 on Python 2. You can easily switch it to v2 using sip.setapi. riverbankcomputing.co.uk/static/Docs/PyQt4/html/…
@something: I didn't say any different, I just said that API v2 isn't enabled for Python 2 by default. Of course, it can always be explicitly enabled (admittedly, I should have said that). This can however cause trouble, if a library you are using still requires API v1, because API v1 and v2 can't be used together in the same interpreter.
@lynaryorn Fair enough, but it should be edited, as it is a bit cryptic (explicit is better than implicit), and the second paragraph is misleading. Two people have been confused by the answer enough to say something here in the comments after reading what you wrote. Probably should add how to do this in PyQt/Python 2. Of course, then that would slightly undermine the reason for recommending PySide over PyQt in the first place (which is what I found misleading). Answer just doesn't hang together that well. Plus, it just isn't true anymore that PySide is close to PyQt in maintenance:v 4 v 5 etc
G
Gerald

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.


You call £350 per developer fairly reasonable, do you? I don't when there's a project around which is just about as good and better in places and getting better still much more rapidly and is free to use. You do run into bugs with it every so often, but they are consistently fixed quickly.
@Chris Morgan: so you'd say development for PySide is more active? Does anyone know btw who is behind PySide? Is it still Nokia? In that case I'd not be too sure about the project's future...
@shutefan: at present PySide seems to me more active; it's continuing working on getting better while PyQt4 is mainly just keeping up with Qt progress. Nokia backs OpenBossa in some way (I don't know the precise arrangement) and they are in charge of the PySide project. I have been wondering about what will happen with all Qt stuff - Qt, PyQt4, PySide, et cetera. - when Nokia goes under (gets bought) as it seems likely will happen fairly soon. And my answer is: I don't know; but it seems to me unlikely that any of these things would not be allowed by their communities to collapse.
@Gerald: true, Nokia is stopping funding it, but discussions on the future of the project seem to me to be heading in the right direction and I suspect it will be sponsored by another entity. What's the problem with LGPL? I say that I would not consider £350 for a PyQt4 license reasonable because I consider PySide to be generally better.
"This could make a difference if you don't wish to make your project opensource". Actually, this is wrong, it makes a difference if your proyect is non-GPL. I'm working on an open source proyect; BSD licensed, and PyQT is too restrictive for these scenarios, and £350 is a no-go for an open-source proyect.
S
Simon Hibbs

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.


Since I wrote this the PySide project has become moribund, but it's still a decent code base. My app still runs fine and the bugs I hit were either fixed, or trivially worked around. I may move back to PyQt at some point, but feel no urgency in doing so.
PySide is not dead....
C
Chris Morgan

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.

The files used:

pyqt4pysideimporter.py

zip_imp.py (for py2exe support)

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.


You say it's smaller on Windows; by how much and what about other platforms?
@shutefan: when all scrunched up optimally (see make_py2exe.py - an optimal set of flags for py2exe plus compression with UPX), I think the difference was something like 8MB instead of 9-10MB (that is, including the full Python runtime and all my stuff as well), but I can't remember the figures precisely. On Linux, the .so files representing the Python modules are on average around twice the size of the PyQt4 ones.
e
ekhumoro

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.


Does anyone know what the current status is? Does PyQT now have that runtime binding? Can you use PyQT with QML, without any impediments that wouldn't also exist with PySide?
This is no longer the case; PyQt now supports qmlRegisterType and QML binding in PyQt5
S
SoloPilot

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.


It seems like choosing whether to use .NET (PyQT) or Delphi (PySide), which is it will practically safe to say that PyQt will always be one step ahead of PySide.