PyQt or PySide - which one to use

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. — Andrey Agibalov, Jul 31 '11 at 10:04
It may not be much - but this comparison seems fairly up-to-date: http://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. — BergmannF, Jul 31 '11 at 11:10
You also need to consider that PyQt comes only with a GPL license, but pyside is more permissive and is released under LGPL. — Anoop, Aug 05 '11 at 07:40
PySide has support python 3 [since 1.0.8](http://qt-project.org/wiki/PySide_Python_3_Support) — troy.unrau, Sep 01 '12 at 17:11

score 36 · Accepted Answer · answered Jul 31 '11 at 12:50

36

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.

answered Jul 31 '11 at 12:50

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 Jul 31 '11 at 13:36
2

@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. – Jul 31 '11 at 13:45
2

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. http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/incompatible_apis.html – aukaost Aug 01 '11 at 10:40
@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. – Aug 01 '11 at 13:52
@lunaryorn "I just said that API v2 isn't enabled for Python 2 by default." Where did you say that? Someone should edit and clarify.As it stands, this accepted answer is actually misleading. – eric Sep 10 '14 at 15:41
@neuronet In the very last sentence: “PyQt […] supports this modern API, and uses it by **default** for Python 3, but **not** for Python 2 to maintain backwards compatibility.” Note how “not” negates “default”, leading to the obvious conclusion that on Python 2 the default is API v1. You need to read what I write. – Sep 10 '14 at 15:45
1

@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 – eric Sep 10 '14 at 16:09
PySide has been officially supported by Qt: https://wiki.qt.io/Qt_for_Python – Mr. Developerdude Jun 21 '18 at 16:53

score 28 · Answer 2 · answered Aug 02 '11 at 01:52

28

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.

answered Aug 02 '11 at 01:52

Gerald

609
5
13

12

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 Aug 03 '11 at 14:56
3

@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 Aug 03 '11 at 20:10
2

@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. – Chris Morgan Aug 04 '11 at 11:47
@ ChrisMorgan: Just looked up OpenBossa, which seems to be financed directly by Nokia Brazil: http://web.openbossa.org/about The Brazilian state seems to have a particular interest in their projects and is very pro-FOSS anyway, so they might jump in if Nokia drops support. If Nokia would stop Qt development altogether the KDE Free Qt Foundation would be allowed to release Qt under an open source licence: http://web.openbossa.org/about – shutefan Aug 05 '11 at 13:47
@Chris Morgan: Yes. The fact that something else is available is irrelevant. I know it would take me way longer than £350 is worth to write anything as useful as PyQt and PySide. Also remember that for some people LGPL is unacceptable and therefore isn't 'free'. As far as the future goes, Nokia is pulling funding for PySide at the end of the year (2011). I expect the project will survive but the rate of development will surely slow without some cash injection from another entity. – Gerald Aug 30 '11 at 04:15
1

@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*. – Chris Morgan Aug 30 '11 at 08:01
@Chris Morgan I don't think there is a problem with the LGPL. But I have come across situations where it is against company/client policy to use LGPL code. I speculate that this is due to association with the GPL and legal departments making uninformed decisions to 'be on the safe side'. However, it still means you can't use PySide in those instances. I'd like to point out that, personally, I have only used PySide for projects since it was reasonably stable. – Gerald Sep 07 '11 at 03:36
4

"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. – WhyNotHugo Feb 16 '12 at 01:35
Just an update: PyQt license is £390 now. – J...S Aug 22 '18 at 07:26
390 is the big enemy of human kinds. – frankliuao Apr 04 '19 at 03:06

score 18 · Answer 3 · answered Aug 23 '11 at 10:44

18

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.

answered Aug 23 '11 at 10:44

Simon Hibbs

5,941
5
26
32

2

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. – Simon Hibbs Jun 03 '13 at 09:57
2

PySide is not dead.... – eric Mar 06 '15 at 03:19
1

It looks like there are some good news about PySide and Qt5 support: https://wiki.qt.io/PySide_Roadmap , http://lists.qt-project.org/pipermail/pyside/2015-April/002285.html and http://lists.qt-project.org/pipermail/pyside/2015-June/002298.html – gmas80 Jun 12 '15 at 17:39

score 10 · Answer 4 · edited Oct 09 '12 at 16:37

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? — Dan Ross, Feb 03 '17 at 23:52
This is no longer the case; PyQt now supports qmlRegisterType and QML binding in PyQt5 — jpyams, Dec 31 '17 at 15:41

score 9 · Answer 5 · answered Aug 02 '11 at 03:37

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, Aug 02 '11 at 14:52
@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. — Chris Morgan, Aug 02 '11 at 22:43

score 5 · Answer 6 · answered Jun 26 '13 at 13:56

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. — swdev, Dec 16 '13 at 00:09

PyQt or PySide - which one to use

6 Answers6

Linked