Letting you know about the existence of Qt.py

[mottosso]

Hi qtpy!

Me and fellow developers are working on a shim much like yours, except with a different mindset and target audience (i.e. film and visual effects). We aren't yet sure whether our approach is better or worse than yours, but expect changes to eventually occur relative our narrow target audience to conflict with those of yours (assuming yours is the Spider IDE and/or the general public, though do correct me if I'm wrong!).

• https://github.com/mottosso/Qt.py

Our goals are to:

1. Remain a single-file implementation.
2. Enable code written explicitly for PySide2 to run on any other binding.
3. Not implement anything; just remap Qt 4 bindings to Qt 5 (again, to PySide2 specifically)
4. Document and aggressively test differences.

We'll be keeping an eye on your developments and hope our coexistence will make us both stronger. I hope we can be friends!

[ccordoba12]

Hey, thanks for letting us know about your project @mottosso!!

I have a couple of questions about your goals:

Remain a single-file implementation

Why do you prefer that? It seems a bit unmanageable in the long run ;-)

Enable code written explicitly for PySide2 to run on any other binding.

Why? PySide2 seems to not be ready for the prime time :-)

---

Given that you seem to have a lot of experience with PySide, I think we should join efforts and work on a single shim package that would work really well for both PySide and PyQt.

It's true that we developed qtpy for Spyder, but we are open to work with the community to suit the needs of any project. Besides Spyder, there are other projects that are already using qtpy: Anaconda's Navigator, git-cola and Glueviz. And that's really good because now qtpy is being put to test on situations that we don't really predicted at the beginning :-)

What do you say?

[goanpeca]

Hi @mottosso thanks for chiming in.

Regarding...

• Remain a single-file implementation.

I guess this in the linex of a six like idea?, but for our use case (plus testing) it does not make much sense.

• Enable code written explicitly for PySide2 to run on any other binding.

As @ccordoba12, even though pyside2 has been officially gained momentum it seems to not be ready AFAIK

Not implement anything; just remap Qt 4 bindings to Qt 5 (again, to PySide2 specifically)

Since the API changed and is expected to keep changing this approach might hit some issues.

Document and aggressively test differences.

We are already starting on this and we are including patches so that users can confidently use Qt5 all the time even if using Qt4. We chose to follow (mostly) the PyQt5 api cause it was ready (pyside was nowhere near that goal at the time this project started), but at the end PySide2 and PyQt5 will end looking the same (or close). We will still give priority to PyQt5 over Pyside2 (when it arrvies) so that the chain of use is

PyQt5 -> PySide2 -> PyQt4 -> PySide -> Error!

---

I support @ccordoba12 on that we should work together and focus in giving more (full?) support to pyside2.

Additional to this, I think is not such a good idea to have a package that has a very similar name but takes a different approach. Having a package named QtPy, when PyQt already existing WAS confusing, but as @ccordoba12 points out, now several projects are already using it so it has somehow consolidated.

[mottosso]

No problem @ccordoba12!

Why do you prefer that?

Fair question. It's got to do with our target audience; they are not developers, but rather artists with scripting experience. We can't rely on pip, anaconda or any other packaging mechanism, when the lowest common denominator is "copy/paste this file". Support for package managers is there, but optional.

It seems a bit unmanageable in the long run ;-)

I can see why you'd think that. :) In this case we expect it to go both ways - sticking to one file forces us to keep this one file short and maintainable, and keeps us honest about goal 3.

Why? PySide2 seems to not be ready for the prime time :-)

It's a gamble. We're expecting PySide2 to become the new sorcerer supreme in the not too distant future, and we'd like to support that effort. We expect it to correlate better with the C++ version of Qt in the long run, simply due to its relation to The Qt Company.

But again, it's a gamble and as of now it can go one way or the other. For all we know, the project can fail completely, and at that point we'd have to adapt.

I think we should join efforts and work on a single shim package that would work really well for both PySide and PyQt.

I admire your optimism! However, as we've already experienced, there are a few conflicting requirements neither of us are able to fulfil in one offering - one being the target audience requirement, as mentioned above - another being whether or not to provide ad-hoc implementations to differences across bindings - a third one being; which should be our reference binding?

I think we will do better catering to these different extremes - learning from each other, sharing what we can.

@goanpeca Let me know if the above doesn't answer your questions as well and I'll fill it in!

Thanks guys!

[goanpeca]

Hi @mottosso

Sure, almost has been answered just to point out

• One being the target audience requirement, as mentioned above

I think packaging exists for a reason and if people use anaconda they can already install things using a graphical package manager that makes the barrier of entry easier (See Navigator. Copy paste might be the "right" solution for your use case, feels like going back 20 years.

• another being whether or not to provide ad-hoc implementations to differences across bindings

This could be easily switched on and off so that it could fir your use case, so that no patching is applied depending on a flag, or a config file (if you still prefer copy pasting files over setting env variables..)

a third one being; which should be our reference binding?

This is a bit irrelevant cause they look the same except for some thing that we unify on QtPy (Like using Signal and Slot instead of PyQtSignal and PyQtSlot). Also which one is used by default can be set so you could have both pyside and qt installed but force the use of one (again.. config file or env variable). Even if they include larger differences we could very much also include some configuration to either make the code look like PySide2 or like PyQt5,

The reference should be Qt and that is the first goal cause the bindings include extra stuff that is not necessarily Qt, but helpers.

---

We are definitely not going to use a single file (copying a single folder is just as easy as copying a single file 😄.

Except for that requirement I don't see any problems with implementing your approach as extra config settings.

[mottosso]

I think packaging exists for a reason and if people use anaconda they can already install things using a graphical package manager that makes the barrier of entry easier

As a developer, I'm with you on this one! The habits of our target audience however falls outside of my control. :(

This is a bit irrelevant

Oh but I disagree! The difference is huge! At this point, it sounds as though qtpy is an ad-hoc mixture of available members, what about discoverability? How can I make an educated guess about the choices you've made, if they aren't based on a single truth?

This is the reason we've chosen one and only one reference, and let others follow. The end result is, if you only know PySide2, you'll do fine. If not, you must learn PySide2. This knowledge is then transferable to.. exactly, PySide2.

This could be easily switched on and off so that it could fir your use case

About configuration files/environment variables; it's not a bad idea, and it can work. But I don't agree it's a good idea. One reason being the inherent complexity of doing that, another being that it would fragment projects that use the shim; requiring multiple configurations to potentially co-exists within the same interpreter session. Complex indeed!

---

But this is exactly my point - I disagree on these things, but I'm not right. Neither of us are. This is why I think we must both exist and do what we think is right. Users will share some if not most of either your views, or ours, and now they can choose.

[goanpeca]

Oh but I disagree! The difference is huge!

I have no idea what you mean, cause our reference is Qt5 docs (not Qt4, not pyside, not pyqt4 not pyqt5 not pyside2). We mostly follow PyQt5 (which is based on Qt5 anyway) cause that is what is available now.

[goanpeca]

Anyway, thanks for letting us know and good luck!

[mottosso]

You are most welcome, @goanpeca.

good luck! [closed]

"Good luck and speak soon!"? :) Or "Good luck and good bye"? :(

[goanpeca]

Good luck and let us know how the project is going :-p hehe

[adrianog]

Hi

Thanks for both initiatives. Which one do you suggest we use at this point in time?

[mottosso]

Hi @adrianog if it's me you're asking, then try both and let us know which you prefer and why!

[adrianog]

Thank you @mottosso but I would rather form an idea reading / gathering info first. Especially on issues that might not be immediately clear just by hacking around, carring out a (simplistic) test.

Has anything changed in the last year with regard to the differences between these two projects as highlighted in this discussion? It might benefit other readers besides me.

Especially the focus for QtPy:
PyQt5 -> PySide2 -> PyQt4 -> PySide -> Error!
vs (as I envisage it)
Qt.Py:
PySide2 -> Error!

Is that still the case?

The packaging aspect already makes me lean towards QtPy, but might not be a dealbreaker.

Do you still see PySide2 in the same way going forward, one year later?

[mottosso]

I'm a little cautious about comparing the projects, due to my involvement in one of them, but at the very least I'm happy to say that the resolution method is similar but in a slightly different order per default.

    Default resolution order:
        - PySide2
        - PyQt5
        - PySide
        - PyQt4

• Reference
• Implementation

Overridable via the environment variable QT_PREFERRED_BINDING.

Example

import os
os.environ["QT_PREFERRED_BINDING"] = os.pathsep.join(["PyQt5", "PySide2", "PyQt4", "PySide"])
import Qt
assert Qt.IsPyQt5 == True

• Documentation
• Query flags

I can have a look to see if I can make this more obvious from the docs, the resolution order has been the case since day 1.

Do you still see PySide2 in the same way going forward, one year later?

Yes, PySide2 is still going strong at the very least in the Visual Effects community where the target audience for Qt.py is.

The packaging aspect already makes me lean towards QtPy, but might not be a dealbreaker.

If you are referring to Conda, than I'm sorry to say that Conda isn't particularly relevant in VFX and I personally stand very little to gain from distributing it there, but as maintainer to the project I'm happy to take on a pull-request for it, there is a discussion about it here.

Has anything changed in the last year with regard to the differences between these two projects as highlighted in this discussion?

I'm happy to say Qt.py has been adopted by some if not most of the worlds largest VFX shops which is exactly what we set out to do. We are receiving contributions from Disney, Digital Domain, Weta amongst others and smaller shops are following suit as well. We've made tutorials, both commercial and free and the community has been most receiving and appreciative to our efforts.

Other than that, our goal remains the same; many bugs have been squashed and features are added all the time.

The difference remains the same as well; Qt.py is targeted for use in parallel with applications written using the original bindings running in one interpreter session - the benefits of which was recently elaborated on here.

For details on how Qt.py evolves, see here.

Hope it helps, and let me know if you've got any more questions!