PySide 2 vs PyQt maturity
As of today (50 years after Moon Landing), how "mature"/"comprehensive" is Qt's PySide 2 offering, compared to PyQt?
When I started out on Qt 2 or 3 years ago, I looked at PySide and there were whole swathes of Qt functionality which were simply not implemented (don't ask me now which).
I use PyQt, which is mature & comprehensive. It receives nightly fixes where necessary. The innards are complex, and sometimes one needs to understand them to achieve something.
I would be tempted to move to PySide 2 --- either for large existing project or perhaps only on new projects --- not least because of the licensing issue. But cannot do that unless it is now fully able to cope with everything PyQt can.
Does anyone perhaps have any experience of both, or recent stories about migrating from PyQt to PySide?
Currently (as of the last time I checked -- just a few months ago) PySide2 is lagging behind pyqt5 but both are based on Qt5 so are fairly similar. Further I have not heard any reason why someone would want to use PySide2 over pyqt5. The only comment that I heard in relation to this was that pyqt5 (supplied by the makers of Qt5 if my information is straight) detrimentally affected the usage of PySide2 since it was more up to date than PySide2
So my suggestion to anyone has been -- Use pyqt5 as it makes no sense to add a third party into the mix as being dependent upon more entities always gives more room for issues -- especially when that extra entity is dependent upon the same entity for the base item. Basically it would be like buying your Widget from John who buys it from Frank and puts a different label on it when you could go to Frank and buy that same Widget without that label -- so unless you need that label for some reason -- the base product is the same and you do not have to worry about John and/or Frank getting sick and not being able to supply the Widget all you have to be concerned with is if Frank gets sick.
Of course you have the added issue of PySide2 being an open source project meaning that it is pretty much user driven in its functionality completion which, having worked with other open source products, is always a sticky-wicket to deal with unless you (and/or your company) are willing to dive in and do a lot that work yourself.
Hi, thanks for commenting. But I must correct a couple of your statements.
Yes, it is the fact that (open source) PySide 2 is LGPL, like Qt itself, whereas PyQt is GPL, that is a big consideration for most of us when picking a Qt for Python brand.
Don't say "PySide 2 is a sticky wicket because it's open-source". Unless you have purchased a paid license for Qt, most people in this forum are using the Open Source version of Qt (for C++). So PySide 2 being open source is neither better/worse/stickier than the Qt it goes with.
As for your
Use pyqt5 as it makes no sense to add a third party into the mix
in fact it is PyQt which is already the "third party" added into the mix. PyQt is from Riverbank, a third-party, whereas PySide 2 is from the Qt company, just like Qt. So it is PySide 2 which is not the "third-party" here. If one applied your argument here --- which does have a certain merit --- it would dictate the opposite of what you say, i.e. use PySide 2 rather than PyQt.
pyqt5 (supplied by the makers of Qt5 if my information is straight)
No, you have it the wrong way round. PySide is supplied by the Qt company, not PyQt.
Hmmm okay I stand corrected (thanks by the way) on a few points that I was a bit foggy on to begin with -- but all-in-all I find it most interesting that pyqt5 (a child product of Qt5) a seeming lesser (further removed) sibling to PySide2 is seemingly more advanced than PySide2? Can you explain that one to me?
That aside the only really big difference it appears in pyqt5 versus PySide2 where PySide2 has the edge seems to be the LGPL vs GPL thing which I concur can be an issue for some folks and something that does need to be taken into consideration. I will keep that in mind going forward.
Note I did not say PyQt was a sticky-wicket -- I said all Open Source software is a sticky-wicket and I say that be because so far in my experience it has always been a sticky-wicket versus production grade software and is always an item that gets placed on the table when deciding whether to use something over something else -- which is to say if Open Source was not a concern it would never enter into any criterion decisions. Now just because something is a sticky-wicket does not mean it is not the best product out there -- it just means it has particular concerns that have to be taken into account if it is going to be used.
Please yourself as to whether you call "pyqt5 (a child product of Qt5)". To me it is not. It is a third-party who chose to develop it.
PyQt is "futher advanced" than PySide because it's had a (much) longer development. Until recently, PyQt was the de facto standard for Qt in Python, and you'll see a lot more questions/answers out there compared to PySide. It is only recently (last year? I forget) that PySide went to PySide 2, and only that can hope to rival PyQt, PySide "1" was very incomplete.
@JonB I only call pyqt5 a child of Qt5 because that was based on something I read about it -- aka pyqt5 is based on Qt5 which means Qt5 came first and pyqt5 being based on Qt5 is thus subsequently a child of Qt5 or at least that is what I understand that language to mean.
Especially when you come across other text that states things like pyqt4 and pyside were both based on Qt4 and now pyqt5 and pyside2 are both based on Qt5 as well was other contextual content that eludes to Qt being the parent product that these other products are based on.
Thus in summation if Qt is the parent and these other products are based on it -- that by definition -- makes these other products children of Qt.
Also if interpret your answer correctly you are stating that pyqt5 is a much more stable/reliable product than its sibling pyside2