
Hello Qt for Python - pekalicious
http://blog.qt.io/blog/2018/05/04/hello-qt-for-python/
======
mherrmann
Very happy to hear this as the author of a PyQt-based file manager [1] and an
open source library for solving the many headaches that come with developing
desktop apps [2]. Once Qt for Python is stable enough, I'll be happy to switch
to it from PyQt.

[1]: [https://fman.io](https://fman.io)

[2]: [https://github.com/mherrmann/fbs](https://github.com/mherrmann/fbs)

~~~
StavrosK
What would you recommend to someone who wants to write Python desktop
applications today? I've used wxWindows way back when, and I'd hate to use
Electron. Would you go with Qt for Python, or PyQT?

Also, what's PySide/PySide2?

~~~
kbumsik
As you can see, Qt for Python is not yet stable release. So you will want to
use PyQt5 first. I remcommand PyQt5 because there are more resouces available
on the internet now.

PyQt5 and Qt for Python is a 1-to-1 binding to the original Qt and their APIs
are almost identical, so you should be able to switch to Qt for Python quite
easily when it is stable.

By the way, Qt for Python is re-branded from PySide2. They are the same.

~~~
fernly
Would it be as simple as a global change of all "from PyQt5" to "from PySide"
in all import statements?

~~~
kbumsik
Almost, when switching from PyQt4 to PySide 1. It was roughly equivalent with
some minor differences. It was much less work than switching Python 2.7 syntax
to 3. There are some bindings as well [1].

I don't know much detail about PyQt5 vs PySide 2 but at least the overall
logic should be the same.

[1]:
[https://github.com/epage/PythonUtils/blob/master/util/qt_com...](https://github.com/epage/PythonUtils/blob/master/util/qt_compat.py)

------
ntoll
FWIW I use PyQt5 in a code editor project I maintain. While all GUI frameworks
have hiccups and smells to various degrees, Qt and PyQt5 has been, relatively
speaking, the strongest UI framework I've encountered for Python. Why? Ease of
development, cross-platform reach, "batteries included" (e.g. accessibility
features, important for my project), friendliness of the API and breadth of
features immediately spring to mind.

Perhaps PySide's return will encourage some competition in the Qt space for
Python. For example, I wish it was simple to create a cross-platform installer
for stand-alone Python apps that use Qt. Current solutions suffer from the
80/20 rule where the 20 usually contains something essential.

~~~
mherrmann
Sorry to be spamming here but check out my
[https://github.com/mherrmann/fbs](https://github.com/mherrmann/fbs). It is
literally the solution to your pain point.

~~~
fernly
No, interesting and useful. But a few questions. So basically you have
automated the job of calling PyInstaller to make a standalone app, plus the
step of wrapping the app in an installer. Yes?

In order to use this, if I read the tutorial[1] code correctly, I must modify
my app to wrap everything -- or at any rate, all PyQt-related things? --
inside an AppContext, and modify the outermost level to create this.

If so, this is easy enough for the tutorial but what if my app opens multiple
windows and has code to create them spread over multiple modules (as one of
mine does). Is there a simple way to get all these bits into one "context"? Or
have I read too hastily?

[1] [https://github.com/mherrmann/fbs-
tutorial](https://github.com/mherrmann/fbs-tutorial)

~~~
mherrmann
It's more than just automating the calling of PyInstaller. It also fixes some
edge cases with PyInstaller-built apps that lead to crashes on some users'
systems and took me months to figure out. Further, it integrates the solutions
nicely. You don't have to learn how PyInstaller works, fbs does it for you
with very reasonable default settings. You don't have to figure out how you
are going to ship resource files and access them from within your app, etc.

Yes you should use the AppContext. You don't have to convert your entire app
to it. Only enough to "start" your app. (I highly recommend the app context
approach where possible however, it's just so clear.)

------
roblabla
I've always found Qt and Python (PyQt and PySide) to be a weird match. So many
times did I end up with cryptic segfaults in the python VM due to some python
object being collected "too early", creating a dangling pointer in the C++
world. This can happen if you forget to set the parent object, for instance.

I know that those are things you have to worry about when you write C++, but
when in the python world, you kind of expect everything to be refcounted for
you. If I ever have to write a GUI app in python again, I'll probably chose
another framework.

~~~
Drdrdrq
This just means that wrapper around C(++) code doesn't handle resources
correctly. As you said, once inside Python you shouldn't care about object
collection process. Nothing should lead to segfaults, in worst case you should
get an exception about missing parent ref.

~~~
nadioca
more exactly “underlying C/C++ object has been deleted" error.

~~~
JasonFruit
In my experience, those errors are easy to resolve: just assign the new object
to something, so it isn't immediately deleted. A little awkward, maybe, and it
shouldn't happen, but if that's the worst quirk of PyQT/PySide, I can deal.

~~~
nadioca
Those errors are always related with a bad implementation where there is
something holding a reference to the qt python object represented by the
bidding therefore keeping it alive even when their c++ instance has been
already deleted. The solution is to go back to the drawing board and improve
the implementation :)

------
std_throwaway
This seems to be the successor for PySide that supports Qt 5. The old PySide
died some years ago and only PyQt was offering Qt 5 support. Due to some
details PyQt was never officially supported by Qt. Is PySide2 now officially
supported by Qt?

~~~
toyg
Yes, but tbh even PySide was originally "officially supported" by Qt, when
Nokia owned it; and then it was dropped. So the question is whether it will
_continue_ to be supported.

The owners of PyQt (Riverbank) depend on that product to survive; whereas Qt
has bigger fish to fry most of the time. The incentives are very different.

~~~
mkl
It wasn't so much that PySide was dropped, as the whole of Qt was dropped (by
Nokia). PySide development was funded by Nokia, which owned Qt, and done
mostly in a Nokia R&D institute in Brazil (INdT). Nokia sold Qt to Digia, and
Microsoft bought Nokia, so there was no connection anymore between Qt and the
people who developed PySide, and so it stalled.

Digia later spun off The Qt Company, which develops Qt and is now developing
PySide2, so this is actually the first time the same organisation has
developed both Qt and Python bindings for it.

For many purposes (including mine), PyQt is very expensive, so I'm really
hoping PySide2 goes somewhere.

------
adamnemecek
This is like 10 years too late. This could have prevented electron.

~~~
always_good
People use Electron because of web technology and also the abstractions
available there like React, not because any dynamically-typed language
would've sufficed.

In fact, Python is at a disadvantage here anyways because it's not async by
default.

~~~
stefano
What's so important about being async by default to build desktop
applications? Offloading slow tasks to a background thread is not at all
harder and actually allows you to use more than one cpu core.

Threads avoid the need of callbacks/promises/async/await and they're also
cheap and performant unless you need to spawn >10k of them, which seems very
unlikely in a desktop applications.

Being async by default is an advantage when you need to handle hundreds of
thousands of tasks, all of which are mostly waiting on I/O, which is something
that can happen on server side applications, and almost never on the desktop.

------
fladd
Does anyone know of a Qt binding for Python that is actually pythonic (as in
follows PEP 8)? Both PyQt and Pyside are just one-to-one wrappers that use
C-style naming for everything.

I find that really strange. The same holds for most other GUI libraries, like
WxPython.

It seems the only real pythonic GUI libraries are Tkinter and PyGobject.

~~~
mherrmann
It's so much better if it's one-to-one. You can use the same documentation.
The same search terms. You don't have to translate back and forth in your head
all the time. At the end of the day, PEP8 is just a convention and we're free
to break with it where it makes sense. Imho, this is such a case.

~~~
dragonwriter
> It's so much better if it's one-to-one. You can use the same documentation.
> The same search terms. You don't have to translate back and forth in your
> head all the time.

Those are things that make it better for the library maintainers, sure, but
presenting (and documenting) an API that is idiomatic, both in structure and
behavior, for the host language is better for library consumers, as it doesn't
force them to context switch between the idioms of the host language and the
idioms of the foreign library.

~~~
ktpsns
Agree with having a pythonic API.

There are already examples in the "Hello Qt" which are easily solvable:

    
    
      app = QApplication([])
      # should read instead:
      app = QApplication()
    

where the empty list is the default argument. Also

    
    
      app.exec_()
      # should be instead
      app.exec()
    

as it is also in the C++ API.

These small things make the difference.

~~~
mherrmann
exec is a reserved keyword in Python. The _ is there because the code wouldn't
"compile" otherwise.

------
bitL
Sadly, we still don't have the seamless UI building functionality Delphi had
15 years ago, allowing making a fairly advanced desktop app in a day. Jumping
between Qt Designer and IDE back and forth is still an order of magnitude more
complicated than it needs to be.

~~~
drb91
I just took a look at delphi. What’s so unique about its ui builder?

~~~
Drdrdrq
It was (is?) very powerful and at the same time very easy to use. Not sure
about alternatives nowadays...

~~~
ZenoArrow
For .NET, Eto is a good option. It's cross-platform and supports the native
toolkits of the platforms it supports:

[https://github.com/picoe/Eto](https://github.com/picoe/Eto)

There's also Avalonia, but it's currently in beta:

[http://avaloniaui.net/](http://avaloniaui.net/)

------
blattimwind
Qt for Python == PySide2 == PySide for Qt 5.

------
asafira
I'm sure others here have far, far more experience with QT that I do, I wanted
to give my 2 cents: QT has been great for the experimental control software we
run to perform experiments in our lab
([https://github.com/LISE-B26/PyLabControl](https://github.com/LISE-B26/PyLabControl)
\--- note, the readme is unfortunately out of date, but it should be ready in
a week or two). I tried a good number of other GUI libraries for python, but
pyQT just worked far more quickly.

------
mcny
Anyone else getting Heroku application error?

[https://archive.fo/DdJpj](https://archive.fo/DdJpj)

~~~
Matt3o12_
If you click on "history", you can find a version that works, though:

[https://archive.fo/y0YlA](https://archive.fo/y0YlA)

------
lbeltrame
I skimmed through the posts in the thread but no one seemed to mention the
major pet peeve that (IMO) PyQt has, which is not the licensing, but the
development model:

1\. SIP files are generated and dropped into the tarball: no way to do that
yourself (the tool is available, but completely undocumented). This is
problematic when a new major Qt version is out, but PyQt hasn't updated yet (I
had problems like this recently when building PyQt5 for Qt 5.11 for openSUSE)

2\. There is absolutely _no_ bug reporting: you have to join the mailing list,
post about your issue, and hopefully get an answer or "fixed in next snapshot"
(see below)

3\. There's no source repository access, just frequently-released "snapshots".
Backporting patches to stable releases (because perhaps fixes aren't in old
versions) is a chore.

4\. Submitting patches as well requires a ML post: not bad per se, but there's
no real workflow for it (and hard to do anyway without having the current
state of the code).

I don't have to use PyQt professionally (all my stuff is
parsing/querying/stats, so a GUI isn't necessary), but for my free time
projects I preferred to learn C++ and Qt than go through PyQt again. And it's
a shame since the bindings are quite good in quality.

~~~
xioxox
This isn't PyQt, but an update of PySide. However I find the PyQt developer
very responsive to bug reports. It's a much better service vthan the usual
post to a bug tracker and no response you get with many other projects.

------
cup-of-tea
I used PyQt5 quite successfully a while back. This looks very similar. What is
actually new here?

~~~
std_throwaway
PyQt is not PySide. Qt (the foundation) does not officially support PyQt.
PySide (the old one) did not support Qt5. PySide2 does support Qt5.

~~~
toyg
_> Qt (the foundation) does not officially support PyQt._

But the project owners (Riverbank) support PyQt just fine, and arguably much
better than Qt ever supported PySide in any previous incarnation.

------
Buetol
Took me a while to figure out the "pip install" command:

    
    
      pip install --index-url=http://download.qt.io/snapshots/ci/pyside/5.9/latest/ pyside2 --trusted-host download.qt.io
    

(with python 3.6 or 2.5)

------
dokka
I have been waiting for this my entire adult life. That's all I have to say
about it.

~~~
thomastjeffery
What about pygobject? What does Qt have to offer over GTK?

~~~
dokka
I like pygobject too, but I've always wanted a QT library for python not
written by a 3rd party. Most of the 3rd party libs will get you 90% there, but
if QT commits to making the library, they won't leave me hanging. I've been
wanting to build a python desktop app with the newest version of QT with lots
of dynamic UI windows for a very long time, and this will allow me to do it.

------
smnrchrds
Is is possible to use QML in a PyQt/PySide2 app? Using QML for interface and
Python for logic would make perfect sense. But every PyQt article and tutorial
I see is about QtWidgets.

~~~
pknopf
We use PyOtherSide for exactly this. Works perfectly.

I'm also working on a similar solution for .NET Core:
[https://github.com/pauldotknopf/net-core-
qml](https://github.com/pauldotknopf/net-core-qml)

------
77pt77
Archived page because site is really slow:

[https://archive.is/y0YlA](https://archive.is/y0YlA)

------
icefo
This is good ! I remember coding a GUI in PyQt5 when the first usables version
of python 3 came out and it was incredibly painful.

Almost no documentation was avaible and I was learning how GUI works. It took
me a while to get a basic app running and from there I mostly translated the
official docs to python.

------
RandomCSGeek
Why though? Is there some useful benefit that python offers over C++, or is it
just another language support so that people more comfortable with Python
could use it?

If I were ever to write a desktop app, which one should I choose, given I'm
equally comfortable with both languages?

~~~
gawkface
It's like you say, and like the qt blog says, "opening to python world"

About your second question (c++ vs python), even I am curious

------
jimnotgym
I would love to hear more about this from the sages of HN. I really don't
enjoy GUI development in Python. I am not a good enough CS to have the
language to describe what is wrong, but I find it really hard to get Python
GUI stuff to do what I want.

~~~
billsix
Retained-mode GUIs like Qt , wxWidgets, gtk, etc aren't intuitive. Try an
immediate mode GUI, like my python bindings to nuklear

[https://github.com/billsix/pyNuklear](https://github.com/billsix/pyNuklear)

~~~
btown
For more context, immediate mode is much closer to the type of declarative UI
popularized by libraries like React. The invariant is that what is displayed
on screen is always a pure function of some state variable(s), and on any
input/event, instead of needing to "reach into" some retained object that
represents a certain piece of text in a certain pane in a certain window, you
just change those state variables and re-render the entire UI from scratch.
Sounds expensive, but for a 2D UI on hardware that's designed to do far more
complicated things at 60FPS, it's far from the bottleneck.

For instance,
[https://github.com/billsix/pyNuklear/blob/master/demo/overvi...](https://github.com/billsix/pyNuklear/blob/master/demo/overview.py#L305)
(this function is called repeatedly on each frame) is not significantly
different from the example at
[https://reactjs.org/tutorial/tutorial.html#what-is-
react](https://reactjs.org/tutorial/tutorial.html#what-is-react) ... but it is
very different from something like `div = createDiv(); div2 =
createDiv(parent=div)` etc. which would be a retained-mode API.

~~~
billsix
[https://youtu.be/Z1qyvQsjK5Y](https://youtu.be/Z1qyvQsjK5Y)

------
fooker
What happened to PyQt?

Also, the API does not seem Pythonic at all.

~~~
Walkman
I think PyQt is owned by a different company, so Nothing happened to it, I
guess.

PySide is waaaay more Pythonic than PyQt ever was. Types are actually
translated to Python native types and APIs are way more Pythonic and not just
translated 1:1 like PyQt.

~~~
bbernoulli
You've been able to automatically translate types going back to PyQt4 (it's
the default for PyQt5, wasn't changed in PyQt4 due to backwards compatibility
IIRC, but you could opt-in). As mentioned elsewhere PyQt offers properties,
decorators for connecting signals and slots, etc. I found the APIs to be very
similar overall.

------
ChuckMcM
Oh this is very convenient and cool. I'm go looking forward to developing
gnuradio applications using this.

------
pknerd
Will there be need of QT runtime for this?

