Open chadrik opened 3 months ago
With your permission I would publish these to pypi as types-Qt, and I would add a PR here to replace install_requires=["types-PySide2"] with install_requires=["types-Qt"].
Sure, go right ahead. I have no opinion on it, as I don't use typing with Qt myself.
A future challenge will be how to deal with PySide6 support (#367) as it pertains to the stubs
It looks like we're keeping compatibility with Qt 4 and 5 when introducing 6 (https://github.com/mottosso/Qt.py/pull/394), so the resulting types should remain unchanged.
Hi @mottosso!
A Qt.py user reported this to me, and luckily I can take care of the problem on my own, but I need your input.
Here's a quick refresher.
In https://github.com/mottosso/Qt.py/pull/371 we decided to add simple .pyi files to the Qt.py distribution that redirect to PySide2 stubs, and we added
install_requires=["types-PySide2"]
. We arrived at this design for a few reasons:PySide2
means that users can replacetypes-PySide2
-- which is installed by default with Qt.py -- with alternatePySide2
stubs of their choosing, and Qt.py will use those, by virtue of the redirect.Problem
A downside of this approach has been pointed out to me. IDEs (correctly) infer that the owner of the
Qt
objects isPySide2
, so they will often generates code for users that refer toPySide2
objects. For example, when overriding a method, it produces this result for the argument type ofshowEvent
:Expectation
What we want is the following:
(Depending on the IDE, it may add
Qt.QtGui.QShowEvent
)Solution
The only fool-proof solution that I know of that should work for all IDEs that understand pyi files is to create stubs explicitly for
Qt.py
, which would be a copy oftypes-PySide2
with all references toPySide2
replaced withQt
. This would be extremely easy for me to do as part of my https://github.com/chadrik/cg-stubs project. With your permission I would publish these to pypi astypes-Qt
, and I would add a PR here to replaceinstall_requires=["types-PySide2"]
withinstall_requires=["types-Qt"]
.The primary downside that I see is that we lose benefit 2, above. A future challenge will be how to deal with
PySide6
support (https://github.com/mottosso/Qt.py/issues/367) as it pertains to the stubs, but the suggested plan does not make that situation any worse, in fact having custom-generated Qt stubs gives us more flexibility.For the record, this relates to the long-standing issue https://github.com/mottosso/Qt.py/issues/199
Let me know what you think.