PyQt or PySide - which one to use [closed]

Asked 31/7, 2011 at 9:58 Answered 26/6, 2013 at 13:56

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.

Steelworks answered 31/7, 2011 at 9:58 Comment(4)

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. – Hyperparathyroidism 31/7, 2011 at 10:4

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. – Levigate 31/7, 2011 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. – Bryan 5/8, 2011 at 7:40

PySide has support python 3 since 1.0.8 – Vladimar 1/9, 2012 at 17:11

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.

Flamethrower answered 31/7, 2011 at 12:50 Comment(8)

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... – Steelworks 31/7, 2011 at 13:36

@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. – Flamethrower 31/7, 2011 at 13:45

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/… – Trantrance 1/8, 2011 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. – Flamethrower 1/8, 2011 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. – Improvement 10/9, 2014 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. – Flamethrower 10/9, 2014 at 15:45

@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 – Improvement 10/9, 2014 at 16:9

PySide has been officially supported by Qt: wiki.qt.io/Qt_for_Python – Roil 21/6, 2018 at 16:53

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.

Mend answered 2/8, 2011 at 1:52 Comment(10)

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. – Rooftree 3/8, 2011 at 14:56

@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... – Steelworks 3/8, 2011 at 20:10

@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. – Rooftree 4/8, 2011 at 11:47

@ ChrisMorgan: Just looked up OpenBossa, which seems to be financed directly by Nokia Brazil: 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: web.openbossa.org/about – Steelworks 5/8, 2011 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. – Mend 30/8, 2011 at 4:15

@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. – Rooftree 30/8, 2011 at 8:1

@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. – Mend 7/9, 2011 at 3:36

"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. – Spur 16/2, 2012 at 1:35

Just an update: PyQt license is £390 now. – Shepherd 22/8, 2018 at 7:26

390 is the big enemy of human kinds. – Alphonsoalphonsus 4/4, 2019 at 3:6

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.

Azov answered 23/8, 2011 at 10:44 Comment(3)

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. – Azov 3/6, 2013 at 9:57

PySide is not dead.... – Improvement 6/3, 2015 at 3:19

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

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.

Swordtail answered 9/10, 2012 at 16:9 Comment(2)

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? – Huppert 3/2, 2017 at 23:52

This is no longer the case; PyQt now supports qmlRegisterType and QML binding in PyQt5 – Millda 31/12, 2017 at 15:41

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.

Rooftree answered 2/8, 2011 at 3:37 Comment(2)

You say it's smaller on Windows; by how much and what about other platforms? – Steelworks 2/8, 2011 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. – Rooftree 2/8, 2011 at 22:43

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.

Tanbark answered 26/6, 2013 at 13:56 Comment(1)

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. – Opsis 16/12, 2013 at 0:9

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags