PyQt vs PySide

PyQt vs Qt for Python (PySide2)

6 minutes read

In this article, you will learn the differences between PyQt and Qt for Python PySide2 so you can decide which Python Qt binding you want to use.

Why two Python Qt bindings?

When reading this article, you will probably be confused about why there are two Python bindings for the Qt GUI framework and not only one. To understand this phenomenon we have to take a look Qt's history.

PyQt exists for a long time and is supported by Riverbank Computing Limited, a small (one-person?) consulting firm. Back in the days when Qt was owned by Nokia, Nokia decided to create their own Qt binding PySide. The reason for this is very likely that PyQt is licensed under GPL and a commercial license.

Unfortunately, Nokia was bought by Microsoft and Qt, which primarily used to develop GUIs for Symbian, was sold to Digia. Since then, PySide was solely supported by the open source community and for the most part, lacked behind PyQt.

Christian Tismer picked up the work on Qt5 support in PySide2 in 2015 for AutoDesk and created a first merely usable version. In 2016, the project was internally picked up by the Qt Company.

In 2018, support for PySide2 was officially announced up by the Qt Company, the official company behind Qt. At the end of 2018, the first version of Qt for Python, the new name for PySide2, was released.

Differences

For the most part, PyQt5 and PySide2 are very similar. The Qt for Python API is even designed to be compatible with PyQt5.

Moreover, I'm going to explain the difference in the following areas in detail.

  • License
  • API completeness
  • Tools
  • Community and support
  • Binding generator

License

The most significant difference between PyQt5 and PySide2 is the license. PyQt5 is released under the GNU GPL v3 and the Riverbank Commercial License. Qt for Python is available under the LGPL v3 and the Qt Commercial License.

The PyQt5 commercial license costs 550$ net with one year support. The price for a commercial Qt license varies depending on the size of your company and your application.

What does this mean for your application? If you are developing open-source software, for the most part, it doesn't matter. However, in some cases, for example, when you want to build an open-source application that can be used in closed-source commercial projects, it may be significant that the dependency libraries don't use the GPL.

When you are working on a commercial application, however, it does matter if you select the GPL, LGPL or any of the commercial licenses. With the GPL you will need to publish the source code of your application and, more importantly, your application also needs to be licensed under a GPL compatible license. For most commercial applications this is unacceptable.

The LGPL however, allows you to distribute your closed-source application along with instructions on how to replace the library.

The commercial license allows you to distribute your application without requiring any instructions. This especially important for embedded devices, when you intend to lock down the users' access to the file system.

However, be aware that the Riverbank Commercial License is only applicable to the Python binding and not Qt itself. So in case you intend to lock down your application, you may need to buy a commercial license for Qt additionally.

Therefore, in my opinion, Qt for Python strongly wins when it comes to licensing.

Tools and Add-ons

The tools that come with the Python Qt binding are rarely discussed when comparing PyQt and Qt for Python.

Some tools

PyQt comes with a whole range of tools. One of the most interesting ones is the pyqtdeploy tool, which claims to be able to deploy PyQt applications for Windows, Linux, OS X, Android and, even iOS.

I have tested the tool, and it seems to work for desktop platforms. However, I couldn't get it to work correctly for Android, due to lack of sufficient documentation.

Moreover, PyQt comes with additional add-ons and libraries including QScintilla2 and dip. Most of the libraries seem to be focused on the use with Qt widgets.

PySide2 currently has no dedicated deployment tool.

PyQt wins when it comes to tools. However, the difference might be insignificant if you use the Python binding to work with Qt Quick.

API Completeness

When it comes to the API, PyQt5 is very similar to PySide2. However, from my experience, I know that both bindings have their flaws.

Qt for Python is still relatively new, and therefore, some essential API functions, including for example qmlRegisterSingletonType are still missing.

From my experience with PyQt5, I also know that QML related features might be missing or untested. For example, I recently discovered that QValidator implementations in Python registered to QML don't work.

Overall, I would say PyQt5 wins this battle compared to PySide2.

Community and Support

An important factor when choosing an open source project or any dependency library over another is the community and support behind the project.

Here PyQt and Qt for Python significantly differ. From a community standpoint, PyQt probably has a larger community. However, the development process doesn't seem to be very open, and it is lead by a single entity.

Community

PySide has lost most of the community from the Nokia days, but since it has been picked up as official Qt binding for Python, it's very likely that the community will quickly catch up. The development process is open and very close to the development process of Qt.

Commercial support for PyQt is cheaper than the commercial support for Qt for Python. However, which quality of support is given, is unclear. The Qt Company, on the other hand, can provide support for all types of customers, including project-based consulting and on-site support.

Also important to notice is the fact that the supporting company behind PyQt, Riverbank Computing, is a tiny company, probably only one person. We hope that it will not happen, but if he/she gets hit by a bus, you are out of luck.

Qt for Python clearly wins this point.

Binding Generator

d
Which Python C/C++ binding generator the binding uses might not be relevant to you if you want to use the library without adding any additional C++ libs. However, if you plan to access an extra C or C++ library from Python, then the choice of the Python binding generator might be relevant to you.

PyQt comes with the SIP binding generator.

PySide comes with the Shiboken binding generator.

From the results, the most critical difference is that bindings generated by Shiboken can accept any kind of input, whereas SIP generated bindings only take types which are known by SIP.

Moreover, SIP can be used to generate Python bindings for C as well as C++ libs. Shiboken, on the other hand, is designed to work with C++.

How to create custom bindings with SIP and Shiboken strongly differs. Let's take a look at a short example.

// Define the interface to the word library.

class Word {
const std::strin the_word;

public:
Word(const std::string &w);

std::string reverse() const;
};

The SIP specification looks as follows:

// Define the SIP wrapper to the word library.

%Module word

class Word {

%TypeHeaderCode
#include <word.h>
%End</word.h>

public:
Word(const std::string &w);

std::string reverse() const;
};

As you can see, the SIP specification code is mostly copy-and-paste of the actual C++ code. Most importantly, every function which should be exposed needs to be defined.

The Shiboken code, on the other hand, looks as follows:

#ifndef BINDINGS_H
#define BINDINGS_H
#include "word.h"
#endif // BINDINGS_H
<!--?xml version="1.0"?-->
<typesystem package="Universe">
     <primitive-type name="std::string">
     <object-type name="Word">
</object-type>
</primitive-type></typesystem>

We have a bindings header file and an XML file specifying a type system. Shiboken generates the API functions automatically generated from the C++ code.

Which binding generator to choose might be personal preference. However, from a maintenance standpoint, Qt for Python wins his battle.

Wrappers

PyQt and Qt for Python both have its advantages and disadvantages. As of the beginning of 2019, the choice between PySide2 and PyQt is not easy to decide.

Luckily, the APIs of PyQt and Qt for Python are very similar. A couple of projects already take advantage of this fact and provide a small abstraction layer over both libraries.

The most popular one is probably QtPy, I use python_qt_binding, the wrapper used in ROS, in most of my projects. python_qt_bindings additionally provides a small CMAKE shim for Shibokem and SIP. This important for projects such as RViz which provide Python bindings for PyQt and PySide.

Conclusion

In this blog post, you learned about the difference between PyQt5 and PySide2 (aka Qt for Python). The side-by-side comparison of the advantages and disadvantages will make it easier for you to decide which Python binding for Qt to choose.

If you don't want to invest too much in one or the other, you can use one of the present wrappers. Using a wrapper is also my preferred choice for current projects.

Your
Machine Koder

Spread the love

Comments 23

  1. Pingback: Choosing Qt for Python or Qt C++? - Machine Koder

  2. Still unclear about licensing.

    I want to use Qt Designer to make an application using pyside code. I want to create an executable of the final application, then make an installer for it using InnoDB. Then I want to try and sell it online.

    Do I need a commercial license to do this? Do I need a license from Qt to do this?

    Thanks.

    1. Post
      Author

      In short, it depends.

      If you close the source code of your application (which InnoDB does not imply), you need to make sure to provide instructions on how to exchange the Qt library for the customer. However, this rule may not apply for B2B projects.

      For more details about using the LGPLv3 license, I recommend you to watch [Burkhard's talk from QtDay.it](https://www.youtube.com/watch?v=bwTlCBbB3RY&list=PLNDFxsfJ30_UOOuyVSAqG-wmXRuLqEJD7&index=18).

      Alex

      1. I'm in the exact same boat as Larry O'Flint.

        He asked it very straight-forward and plainly and exactly how it should be asked.

        I don't want to use Qt Designer. I just want to code PySide2 GUIs and sell them WITHOUT sharing my source code to the actual GUI.

        I don't know what "dynamically link" vs "static link" actually means or how I would even do that - like physically, what does my brain tell my hands and body to do and where do I go and what do I push to achieve this?? I'm so freaking lost.

        Is there a copy/paste license I just include? Do I just need instructions telling people how to install PySide2 ? A text file with pip install PySide2 ? lol

        Where do I get the license texts?

        1. You shouldn't use Python if you need closed source. Even if you freeze your project into a single executable, the scripts will be right there for everyone to read.

          1. Post
            Author

            That's not exactly true, Python bytecode is not very readable - at least it loses all the formatting.

            If you really want to make sure nobody can read your source code, you can also compile it using Cython. The same goes for the QML code.

            But to be honest, most applications these days don't need this level of source code protection since the business logic is somewhere on a server and it's a lot of work to disassemble Python bytecode after all.

            Your Machine Koder

      2. I use Qt Designer to design the UI interface, generate a .ui file, then use pyside2 to dynamically connect, and finally close the source and sell it online. Does it violate the agreement?
        thanks~

        1. Post
          Author

          If you provide instructions on how to replace the Qt library in your application, then it should not. However, best discuss this with a lawyer specialized on the topic of licensing in your country. I can't give any legal advice. To be on the safe side, consider buying a suitable Qt license.

  3. You kind of throw all the different namings in a mixer and choose to reference to whatever pops up in your mind.
    I miss a definition of your various namings:
    PySide2 == Qt for Python?? please reference ONLY PySide2 or PyQt5, thats what we import as python users
    QtPy == QtPy5 or anything else??
    In the Wrappers section it gets even more confusing, what are the wrappers using? PySide2 or PyQt5?

    1. Post
      Author

      The point of this article is to show the differences between the different bindings. So yes, of course, I have to switch between the different names all the time.

      PySide2 == Qt for Python, the official Python binding
      PyQt == PyQt5, the Python binding by Riverbank Computing

      Qt/Python == the Qt Python bindings in general, similar to Qt/C++

      QtPy == one of the wrappers

      The wrappers use whatever version is available on the system. Usually, they prefer PyQt5 or the preference can be modified. Please see the documentation of the wrapper for more details.

  4. Pingback: Python and PyQt: Building a GUI Desktop Calculator - Find your scripts codes

  5. Pingback: Installer PySide2 dans Blender – Matthis Pralat

  6. I'm reading the article, googling for an hour and still don't understand the licensing model. Sorry new to Qt and would appreciate if you make it clear for me.

    I'm writing a Python application. I use PyQt5 for GUI and I do use Qt Designer to create .ui file.
    My question is at the end of the day I want to sell my application. I do not want to give my source code to users. In fact, the access to file system will be locked for them so all they see is a GUI which they can interact with.

    My question is should I use PyQt5 or PySide2? As I said, I don't want to make my application open source neither will give the user my source code.

    Thank you for the article.

    Cheers.

    1. Post
      Author
  7. Sorry in advance for the long post!

    So, I have a slightly different question, or set of questions, than what I see after searching this topic. Most everything I’ve read, and I’m currently watching the YouTube link you provided for Burkhard Stubert at Qt Day, is regarding closed source and/or selling an application.

    I’m admittedly not very knowledgable in the licensing area, but I’ve been *attempting to* research this topic for the last few days. And anything close to my use case (open source tool) is a *very* brief comment that is quickly brushed off as it’s not on topic with the rest of the answer.

    (Quick back story: I have a few ideas for creating tools (I’m an IT Admin) for my fellow IT Admins that have a GUI (reason for Qt) to help them complete tasks that they may not be able to do so otherwise, such as a GUI wrapper to complete tasks by interacting with an API of a management system. I’ve been learning PyQT5/PySide2, but I’m now wondering if the licensing will prevent me from using it... I’m also newer to Python, so I’m not sure if I’m interpreting some key terms correctly.)

    My first scenario:

    So, say I write a tool for my fellow internal admins to use at my company. I also would open source the code for the tool for other IT admins to use in their own organizations. (So no plans to sell. No modifications to Qt/PyQT5/PySide2, etc. Not doing anything crazy here.)

    For my internal use, I wouldn’t even be “compiling” (?) this tool, it would just be a script that would be run on an Admins device to show a GUI. But either the PyQT5 or PySide2 Libraries will be needed, obviously.

    My questions:
    1) Do I need a “paid” license to simply share and use this “open source” tool that I create (internally and/or publicly)?
    2) Do I need to use a specific “license” with my open source code if I host it on GitHub?
    3) If I pre-distribute PyQT5/PySide2 (along with a Python framework) to the devices in my environment (assuming setting this up is beyond the expertise of my users), would this violate any licenses of Qt/PyQT/PySide2?
    4) After watching Burkhard’s talk, I may need to include the Qt license and/or the (L)GPL license in my tools’ GUI?

    I do thank anyone in advance that is able to reply.

    1. Post
      Author

      1) No, the only requirements is that the tool has a compatible license
      2) Yes, anything that's compatible with Qt. If you don't share any Qt source code and binaries, you can in theory even use a more permissive license. Note that the way Python modules are linked into an application, the license boundary is a legal gray zone. Some people argue that you can even close-source the application code and stay compatible with OSS licenses as long as you don't deploy them as a binary.
      3) If its open source, no. If its closed-source you need to provide instructions on how to replace the Qt libraries.
      4) If you are going to sell the tool, then definitely yes. If you make it publically available, then probably too, although as long as the tool is open-source nobody will care. If it's just for internal use, then it's very unlikely someone will be interested in whether you include the license in the GUI or not. But in general, it doesn't hurt to add it.

      Note that I'm not a lawyer and my answers are in no way legally binding.

  8. I'm missing some kind of appreciation of your helpful, well-structured and apparently objective article in these comnents.
    So I leave a big THANK YOU here!
    You helped me a lot in not choosing one of the two ways, but the third: a wrapper.

    1. Post
      Author
  9. Thanks. But I should say that the background color of the website is so annoying, Specially for people who wear glasses.

    1. Post
      Author
    1. Post
      Author

      The graphical part of the application should not be affected at all, since this is the same for C++ and Python. However, your examples fetches data at high rate from the backend, it is expected that the C++ implementation should perform better. If you are worried about performance, you can also implement the performance critical parts of the project in C++ and the rest in Python. There might be performance differences between sip and the shiboken bindings, but I don't have any data on it. I would have expected the two implementations to perform similar.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.