https://github.com/spyder-ide/qtpy/issues/348

[hannesdelbeke]

started a discussion to compare qtpy, a new python module that seems to do the same as Qt.py

it has pyqt6 and pyside6 support, which address this issue https://github.com/mottosso/Qt.py/issues/367 requesting it to be added to Qt.py

so far most tools on github in games & VFX industry still use Qt.py so updating Qt.py would be ofcourse preffered. It'd be great to know also how compatible they are, and what's involved in swapping from 1 to the other.

[mottosso]

A new module?

https://github.com/spyder-ide/qtpy/issues/69

Originally, qtpy modified the PyQt namespace, which was fine for standalone applications but less fine for embedded ones like Maya, where other applications depend on PyQt in addition to the ones that were using Qt.py.

Today, I'm not sure, although the goals of both projects seem consistent so I'd imagine so. Qt.py members are also a lowest-common-denominator, meaning an application written with it would run using PyQt4 as well, which would continue to be true for PyQt6 also.

PR is welcome, even though it seems somewhat premature given all of VFX is still on Qt 5.

[hannesdelbeke]

A new module? spyder-ide/qtpy#69

wow 😮 my mistake 😅 it seemed new since the earliest release on their github was from 2021, and I never heard about it.

PR is welcome, even though it seems somewhat premature given all of VFX is still on Qt 5.

yes only became aware if this due to blender not following the VFX platform standards, and instead using the latest version of python. Which resulted in the typecasting bug in pyblish lite, which I believe is fixed in qt6 but not qt5.

[CAM-Gerlach]

If your use case is VFX, then I imagine Qt.py is probably a better fit for you, since it is specifically designed and optimized for it and is widely used in that community. By contrast, QtPy was originally focused on scientific applications, which is still its primary userbase, though nowadays it sees a fairly broad cross-section of uses in general-purpose programs.

Originally, qtpy modified the PyQt namespace, which was fine for standalone applications but less fine for embedded ones like Maya, where other applications depend on PyQt in addition to the ones that were using Qt.py.

This was indeed true, though we recently (a couple releases ago) removed the last instance where the namespace was monkeypatched.

Qt.py members are also a lowest-common-denominator, meaning an application written with it would run using PyQt4 as well,

As you imply, this is also, in general, an objective of QtPy, though we alias compatible objects that change names between bindings or Qt versions to further improve intra-version compatibility byond a strict LCD. In the recent QtPy 2.0 we dropped support for Qt4, since it and its bindings have been EOL for 6 1/2 years now and were broken (at least without heavy third-party patching) on modern, supported Python versions, we were no longer able to fully CI-test it, and few or no actively maintained projects were still using it. However, existing applications written against QtPy will still work just fine, since it was already abstracting those differences, unless they depended on something that was Qt4-only.

which would continue to be true for PyQt6 also.

We quickly ran into a bunch of thorny conceptual and practical issues trying to bridge the APIs across multiple decades of Qt/binding releases, from bleeding-edge to long-obsolete, which led us to drop support for running against long-EOL, non-LTS Qt releases earlier than 5.9 (and even then, that raises a number of practical difficulties vs. only supporting 5.12+, but we make do). Since user code properly written against Qt.py will still work running on a newer binding, and even currently 5.12 is the oldest version required by the current + 3 guidance of the VFX reference platform, it seems prudent to drop support at runtime for older versions (or at the very least, <5.6) when adding CY2024 support—but that's ultimately up to you, of course.

it seemed new since the earliest release on their github was from 2021, and I never heard about it.

Just to make sure we're all clear, this is just the earliest release tagged with GitHub's new(-ish) Releases feature (which many projects don't use at all, and others sporadically). Per the more canonical sources (Git tags, PyPI releases, Changelog, etc.), you can see that our first official release as an independent package under the name QtPy was March 1 2015, and as mentioned in our Readme, QtPy's history actually extends back to 2011, as it was itself the result of the pyqode.qt, qtconsole.qt_loaders, spyderlib.qt and qlueviz qt-helpers projects all joining forces (the first two mentioned separately in the @mottosso Qt.py Readme, and all long-obsolete and abandoned in favor of QtPy).

Interestingly, the Qt.py Readme states that 0.2.6, which is the first Git tag, was the first release of Qt.py in June 2016, but the earliest PyPI release is 0.2.1 in May 2016—merely a curiosity of historical interest, but I figured it was worth mentioning. To be honest, past a certain point (which both of our projects are), I'm not sure the longevity of the project makes much of a practical difference compared to how actively each is maintained, and all the other factors involved.

[hannesdelbeke]

Thanks for sharing the history & your thoughts behind the development of QtPy. 😊 Very interesting to a newbie like myself

[mottosso]

GitHub's new(-ish) Releases feature

C'mon. 😅

• https://github.blog/2013-07-02-release-your-software/

I found this out by using a new(-ish) feature called "Google".

[CAM-Gerlach]

Still newer than QtPy; that's why I said "-ish" XD