Alex Blasche

Qt for Python 5.11 released

Published Wednesday June 13th, 2018
38 Comments on Qt for Python 5.11 released
Posted in Announcements, Biz Circuit & Dev Loop, Community, Contributors, Customers, Qt for Python

We are happy to announce the first official release of Qt for Python (Pyside2).

As the version tag implies, it is based on Qt 5.11 and therefore the first release that supports the Qt 5 series. At large the project will follow the general Qt release schedule and versions. Although this is still a Technical Preview we will support the release with the usual support pattern (except the compatibility one). Unfortunately, earlier versions of Qt than 5.11 are not supported. It is available for open source and commercial Qt for Application Development users. Note that there is only one package for commercial and open source users. We hope we can receive plenty of feedback on what works and what does not. We want to patch early and often.
Eventually the aim is to release Qt for Python 5.12 without the Tech Preview flag.

The Qt for Python development

It’s been a long journey for this release to come to this point. It started two years ago with this announcement from Lars. Since that day we had a fair share of ups and downs. As the first step, we had to sort out the license situation. We are very grateful for the support and agreements we got from the project contributors during this process.

First development (for our internal Qt for Python team) started based on Qt 5.6 and was mostly focused on stabilizing the code base. With the (at the time) upcoming Qt 5.7 release and it requiring C++11 support a major update was needed for Shiboken (our bindings generator). Similar to qdoc and QtCreator we walked down the path of deferring C++ parsing to clang. Another major construction yard was the documentation. As some might know, the documentation generation pipeline is much longer than Qt’s. It required us to reanimate long lost or dead code in qdoc. Nevertheless we have not given up on being able to simplify this further down the road.

Earlier this year we started the generation of snapshots and we are very grateful for all the comments and bug reports we have received from early adopters in the community. Naturally we will continue to publish the snapshots. Another step on this journey has been a technical blog post series describing some of the possibilities of the project (in chronological order):

If you have not read those blogs yet I suggest you head there and get a first impression. The last milestone has been the adoption of the Python Stable ABI. It enables us to significantly reduce the number of packages as the same package can address all Python 3.5 and later versions.

Get Qt for Python

The release supports Python 2.7, 3.5 & 3.6 on the three main desktop platforms. The packages can be obtained from download.qt.io or using pip with

pip install \
  --index-url=https://download.qt.io/official_releases/QtForPython/ pyside2

Eventually, we hope we can upload the packages to the Python Package Index (PyPi) under https://pypi.org/project/PySide2/. Unfortunately package size restrictions on PyPi could not be lifted in time for the release.

If you want to report a bug, please use the Qt for Python project on bugreports.qt.io. The team can be reached on Freenode #qt-pyside and regularly publishes its progress in the weekly meeting minutes.

Other interesting links:

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Announcements, Biz Circuit & Dev Loop, Community, Contributors, Customers, Qt for Python

38 comments

Petar says:

This is great stuff and a lot of work so kudos to everyone working on this.
Although I’m C++ developer and won’t be using PyQt (not at this time 🙂 this will surely bring new people to Qt and, given a broad libraries python has, it can enable many things much more easily than what one could do with standard C++ at this time (async/await anyone?). Not even mentioning the trouble we have to hire C++ developers these days.
Because of integration with libs like Verimatrix we also need to access Java and Objective C for android and ios which I see is not yet supported in PyQt.

Cristián Cristián says:

This is the part when we shape the future of Qt for Python with the community.
We have been getting a lot of feedback of which new functionalities we can include in future releases of PySide2, and Mobile integration is one of them.
Due to the nature of a tech preview, we are now focusing in providing support to new users, and people that is porting application to PySide2, but I’m confident that we will able to provide nice feature in the next releases.

Gunnar Roth says:

“Unfortunately, earlier versions of Qt 5.11 are not supported. ”
How many version of Qt 5.11 do exist? Which of them is supported then?

Alex Blasche Alex Blasche says:

I updated the blog to make this more obvious. Qt 5.10 or 5.9 for example are not supported.

Elvis Stansvik says:

Will that be fixed? Would be sad if 5.9 LTS was never supported.

Cristián Cristián says:

It’s officially not supported but it’s possible to use it.
You have two options, the one I recommend you is to build PySide2 (branch 5.9) against a Qt5.9 installation, or you can use the snapshots that were generated a couple of days ago: http://download.qt.io/snapshots/ci/pyside/5.9/
But of course, since it’s not supported, PySide2 5.9 branch is not active anymore in the sense that we are focusing on 5.11 for all the bug fixing and adding new features.
If the content of those wheels is enough for you, maybe you can give it a try, but I highly recommend you to move to 5.11.

Ray Donnelly says:

How much effort would a backport to Qt 5.9.6 be in your estimation?

Kirill Balunov says:

Great news 🙂 One thing that does not fit into my head is the “re-branding” to Qt for Python. What is it? If this concept/name is wider than Pyside2, it would be interesting to know about this in more detail. But from the last three posts, there was only confusion in my head while reading “Qt for Python (Pyside2)”. Are there plans to rename and to give a better name to Pyside2 – “as you wanted the name to reflect the use of Qt in Python applications”? If so, it would be cool to do this sooner than later. It’s a bit confusing to always read – Qt for Python parenthesis Pyside2 parenthesis.

If this is a new fresh look with a more responsible approach to this project from Qt company, what is the idea of reusing Pyside name. This name for many does not say anything, also it does not reflect the essence of Qt for Python. For others, this name resembles a project that did not become stable, later it became obsolete, and then it was forgotten for some time. I hope this does not happen again.

Cristián Cristián says:

I agree with your renaming suggestions, but there has been a lot of discussion about this topic, and believe me that all the changes that were suggested in the past triggered many different reactions.

The decay of PySide1 was mitigated when back in 2015 many people started to port it to Qt 5 (since PySide1 was using Qt 4).
The changes from Qt4 to Qt5 were not just “adding new classes”, there were major changes in the binding generator (Shiboken2), the handling of Qt types into Python, etc.

Due to all these changes, the developers decided to rename it PySide2, just to avoid people on thinking it was the same project (in the sense of Qt4 compatible), because it was not backward-compatible.
Even in the last months we had some people asking about PySide1, because there are still people using it.

Before the official release, many people started to generate un-official packages for Anaconda, different linux distributions, among others, so any change was affecting the maintainers and developers.

Why not a whole new name?
because the same arguments you used could be rewritten like “Why changing the name if you want to keep the PySide community?”, or confused people asking “Why you did not continue the PySide project and created a new one?”

Currently, one of the strongest options is to follow the Qt versioning, even for the module name, but this step will require an agreement between the devs and the community.

The Qt for Python name allows us to be more than a set of bindings, and as I previously stated in another comment, we can expand the project to interact with other Qt components.

Paul Miller says:

What version of Visual Studio is the Windows version built with?

Cristián Cristián says:

We used MSVC 2015 for both 64 and 32 wheels.

Paul Miller says:

Thanks for your hard work Cristián. What would be involved to build it all with MSVC2017? Are the existing instructions for building from source still the best way to go?

Cristián Cristián says:

You can follow the instructions here: https://wiki.qt.io/Qt_for_Python/GettingStarted/Windows and just use MSVC2017 instead, also I recommend you to use Python3.5 or superior.

James Sorenson says:

So, will this enable the return to Anaconda?

Cristián Cristián says:

Having a stable set of wheels will, for sure, enable the maintainers of the old PySide anaconda packages to update them, but it’s something that is on Anaconda’s side.

Ray Donnelly says:

Anaconda provides Qt 5.9.6 LTS so I cannot see this happening anytime soon.

An Kr says:

This is good news, I cannot even image the amount of work, you have put into it. Too bad Qt5.9 is not supported though.

Cristián Cristián says:

Still, you can rely on the old snapshots, or maybe build PySide2 from source using Qt 5.9 if it is necessary for your projects.

Laurent says:

Awesome work guys, you’re almost there!

Coming from PyQt, what would be interesting given the historic (from my perspective) falling out of grace of PySide and the stable existence of PyQt, is maybe a centralised comparison between the license and programming implications? Now this information seems to be scattered throughout comment sections, and I find the not mentioning PyQt at all, almost denying its existence through silence, to be strange. Googling “Qt for Python” shows PyQt in the results anyway.

Cristián Cristián says:

We are all aware of PyQt, but our goal is not to compare both modules side by side, since the initial goal is the same: provide python bindings for the Qt project.
We generate bindings using different tools, and maybe you can find minor implementation differences.

I really don’t know the reasons behind the decay of PySide1, but since Lars announced that the project was being officially supported by The Qt Company we have been able to provide a robust set of bindings, and we are currently witnessing how both the project and the community are growing.

I am not aware of the development behind PyQt, but the main difference that I can personally notice is that we don’t want to provide just the “Qt bindings for Python”, but start an integration with many other Qt modules and processes, so we can improve side-by-side with the Qt project.

The next steps in Qt for Python come purely from discussion in our IRC channel, meetups, emails, etc and include topics like Qt Creator, Mobile development, Package deployment, among others.

I invite you to our IRC channel, there we can discuss more about the topic.

tl;dr: our main goal is to be a community-driven project, not just another set of bindings.

Alexander says:

A working PyCharm/CLion/IntelliJ QML plugin would be awesome.

Since I’m working on C++ and Python projects Qt Creator is not a good option at the moment. Also, I’m happy to pay for good IDE as it makes me more productive and therefore pays off quickly.

Yann Lanthony says:

Fantastic news and work !

We’ve been using PySide2 for a while now on our project (https://github.com/alicevision/meshroom), and finally having official wheels is a killer feature for setting up the environment.

BTW, have you any recommendation/plans regarding PySide2 application packaging (i.e generating a standalone executable) ? We’re currently relying on cx_Freeze, which works well but copies the whole PySide2 package in the generated build, including a lot of files we don’t actually need at runtime (examples/typesystems… or binaries like libclang.dll, ~50MB).

PS: Windows wheel for Python 2.7 seems to be missing from the ‘official_releases’
PS2: ‘–trusted-host’ is not necessary for pip install when using the ‘https’ url;
=> pip install –index-url=https://download.qt.io/official_releases/QtForPython/ pyside2
works fine 🙂

Alex Blasche Alex Blasche says:

The server does support https. I updated the pip command line. Thank you.

We are aware of the issues you pointed out and they are a big todo on our list

Johhny Sixpack says:

Will you also fix compiling one’s program with cpython et al? Right now it has some problems with threads.

Cristián Cristián says:

You mean using shiboken to generate your own bindings? or the compiling process of PySide2 ?
If you encounter any problem, please file a bug report in https://bugreports.qt.io/projects/PYSIDE

Johhny Sixpack says:

The compiling process of Pyside2 with threads. I saw there was a bug posted already on it, but it’s marked as out of scope…: https://bugreports.qt.io/browse/PYSIDE-674

Fredrik Averpil says:

Check out fbs for standalone executables with PySide2: https://github.com/mherrmann/fbs-tutorial

eggn1n3 says:

Great work guys!
Question, would there be a list available which platforms are available so I know which wheel file to download?

When I try to install a wheel package for my Linux Mint 17.3 distribution I get the error: “PySide2-5.11.0a1.dev1527584035-5.11.0-cp27-cp27mu-linux_x86_64.whl is not a supported wheel on this platform”

Not sure which wheel file to use?
Thanks.

Cristián Cristián says:

Seems like you are using the wrong wheel.
I recommend you to use the command provided on the blog post or download the wheel from http://download.qt.io/official_releases/QtForPython/pyside2/
the “dev152…” section from the message error points to the snapshot wheels, not the newly released ones.

Adam Twardoch says:

In addition to PySide2 (now Qt for Python) and PyQt, there is also PythonQt, which is a great way of embedding the Python interpreter inside a Qt C++ app and providing a way of scripting the C++ app using Python.

PythonQt’s bindings for the Qt modules and the way the Qt objects are exposed to Python are yet different to PySide’s or PyQt’s.

So my question is: does the Qt for Python project aim at any point to offer an ability such as PythonQt (making Python usable within a Qt C++ app for acripting)?

Cristián Cristián says:

There is an example inside our repository that follows the same idea that you described, but of course is a simple example:
http://code.qt.io/cgit/pyside/pyside-setup.git/tree/examples/scriptableapplication
In simple words, it’s a Qt/C++ app that has a QPlainTextEdit embedded in where you can write Python code and execute it.

Matej Horvat says:

Will it be possible (in the future) to write a Qt for WebAssembly app in Python? Is this planned/feasible?

Thanks!

Cristián Cristián says:

The main idea is to integrate Qt for Python with most of the elements currently available in Qt, but at the moment we are prioritizing other development aspects.
Maybe as a long-term goal it could be considered, but we are not currently working on it.

Adam V says:

I’m trying to port my application from PyQt5 to PySide2 and I’m running into a lot of problems. Is there a live chat/Gitter like place where I can ask some question?

St says:

Hi,
I just installed the PySide2 wheel for Python 2.7 32Bit.

When trying to run the example file “…\Python27\Lib\site-packages\PySide2\examples\multimedia\player.py” via cmd, the following message is prompted:
defaultServiceProvider::requestService(): no service found for – “org.qt-project.qt.mediaplayer”

Can you reproduce this problem at your end?

St says:

PS: I forgot to precise that I’m using:
– Windows 7, 64 bits
– Python 2.7, 32 bits

Cristián Cristián says:

Please file a bug report to discuss this issue.
https://bugreports.qt.io/projects/PYSIDE

Leave a Reply

Your email address will not be published.

Get started today with Qt Download now