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.
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.
I've maintained a production PyQt based app for 7-8 years (started on PyQt4/py2, moved to PyQt5/py3, but I evaluated PySide as well). It involved wrapping another Qt library for use from python. I found the bindings I created based on SIP (which is what PyQt is based on, both written by the same author) to be overall easier to create and smaller in size.
It's great that we're getting Qt backed bindings but Phil Thompson has done a wonderful job with PyQt over the years and I really would've liked to see it become the official library somehow.
Has the python qt installation story improved much recently? A few years ago it was a pain to set up, especially within a virtualenv, which was one of my only complaints with it. Everything else was wonderful.
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.
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.
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?
"PySide2 – the bindings from Python to Qt – changes skin this spring. We have re-branded it as Qt for Python on a solution level, as we wanted the name to reflect the use of Qt in Python applications. Under the hood it is still PySide2 – just better."
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.
Most interfaces created through web technology would be incredibly hard and slow to do using pyside/pyqt. We take for granted the non-blocking aspect of javasript where in python in order to make a slick interface would require to deal with threads/GIL in a much slower interpreted language compared with javascript running on V8.
Qt (Qt Desktop) bindings for python are welcome. But, it's not a suitable for a viable replacement for electron. Maybe Qt Quick, but even qt quick has some decisions that can make incredibly uncomfortable to use in large applications.
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.
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.
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.
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.
Delphi is still around, as is the open source clone Lazarus. It's certainly not as popular as it used to be but still actively developed with people using it.
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 --- 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.
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.
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.
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.
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.
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?
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.
[+] [-] mherrmann|8 years ago|reply
[1]: https://fman.io
[2]: https://github.com/mherrmann/fbs
[+] [-] ntoll|8 years ago|reply
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|8 years ago|reply
[+] [-] bbernoulli|8 years ago|reply
I've maintained a production PyQt based app for 7-8 years (started on PyQt4/py2, moved to PyQt5/py3, but I evaluated PySide as well). It involved wrapping another Qt library for use from python. I found the bindings I created based on SIP (which is what PyQt is based on, both written by the same author) to be overall easier to create and smaller in size.
It's great that we're getting Qt backed bindings but Phil Thompson has done a wonderful job with PyQt over the years and I really would've liked to see it become the official library somehow.
[+] [-] makmanalp|8 years ago|reply
[+] [-] roblabla|8 years ago|reply
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|8 years ago|reply
[+] [-] std_throwaway|8 years ago|reply
[+] [-] msie|8 years ago|reply
"PySide2 – the bindings from Python to Qt – changes skin this spring. We have re-branded it as Qt for Python on a solution level, as we wanted the name to reflect the use of Qt in Python applications. Under the hood it is still PySide2 – just better."
[+] [-] toyg|8 years ago|reply
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.
[+] [-] Walkman|8 years ago|reply
[+] [-] mherrmann|8 years ago|reply
[+] [-] adamnemecek|8 years ago|reply
[+] [-] pjmlp|8 years ago|reply
Just like its predecessors I give it one or two years more max, then it will fade away like they did.
[+] [-] nadioca|8 years ago|reply
Qt (Qt Desktop) bindings for python are welcome. But, it's not a suitable for a viable replacement for electron. Maybe Qt Quick, but even qt quick has some decisions that can make incredibly uncomfortable to use in large applications.
[+] [-] jcelerier|8 years ago|reply
[+] [-] always_good|8 years ago|reply
In fact, Python is at a disadvantage here anyways because it's not async by default.
[+] [-] chimen|8 years ago|reply
[+] [-] fladd|8 years ago|reply
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|8 years ago|reply
[+] [-] fladd|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] bitL|8 years ago|reply
[+] [-] opencl|8 years ago|reply
[+] [-] jcelerier|8 years ago|reply
... uh ? the designer is part of the ide... nowadays you even have a code view synced with the UI editor in realtime (http://blog.qt.io/blog/2017/05/24/qt-quick-designer-qt-creat...)
[+] [-] drb91|8 years ago|reply
[+] [-] blattimwind|8 years ago|reply
[+] [-] asafira|8 years ago|reply
[+] [-] mcny|8 years ago|reply
https://archive.fo/DdJpj
[+] [-] Matt3o12_|8 years ago|reply
https://archive.fo/y0YlA
[+] [-] 77pt77|8 years ago|reply
[+] [-] ktpsns|8 years ago|reply
[+] [-] lbeltrame|8 years ago|reply
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|8 years ago|reply
[+] [-] cup-of-tea|8 years ago|reply
[+] [-] Buetol|8 years ago|reply
[+] [-] dokka|8 years ago|reply
[+] [-] thomastjeffery|8 years ago|reply
[+] [-] smnrchrds|8 years ago|reply
[+] [-] 77pt77|8 years ago|reply
https://archive.is/y0YlA
[+] [-] icefo|8 years ago|reply
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|8 years ago|reply
If I were ever to write a desktop app, which one should I choose, given I'm equally comfortable with both languages?
[+] [-] jimnotgym|8 years ago|reply
[+] [-] fooker|8 years ago|reply
Also, the API does not seem Pythonic at all.