PyQt6 stubs

Philippe Fremy phil at freehackers.org
Wed Aug 3 20:44:08 BST 2022


Hi Phil,


>> As you found out, we have a work-in-progress project for PyQt6-stubs.
>> Like many open source projects, it progresses with volonteers
>> availability and recently, progress has been low on this one. I intend
>> to change that during August.
>
> As I have said before I would prefer to receive bug reports so that 
> the root causes can be fixed to the benefit of all SIP projects. As I 
> don't use mypy myself then those bug reports would need to patiently 
> explain what changes are needed and why.
>
> Phil

Unfortunately, the list is quite long. I am not sure how to file a 
proper bug report, and even if the fix could be handled at the sip 
level. Many stub fixes are linked to Qt's design or mypy syntax.

Getting stubs to correctly describe Python code capabilities can be tricky.

To give you a short overview, the things we fixed in the stubs can be 
splitted in the following categories :


1. all signals are described as function, which is incorrect. A signal 
is an object which is bound during instanciation. So we fix all signals 
definition from a function declaration to something more elaborate (an 
unbound object + a bound object)


2. all methods which may accept None as parameter. Typically, all widget 
constructors have an optional parent widget, which can be None. 
Currently, the stubs will describe this as :

          def __init__(parent: QWidget): ...

But the correct definition is :

        def __init__(parent: typing.Optional[QWidget]): ...

This applies basically to every Qt method accepting a pointer to 
something, which may also be NULL. Quite a few of them. This we fix 
manually as they get reported by users.


3. Missing operators for class that support them. For example, QSize and 
QSizeF support some additions and scalar multiplications. 
QTreeWidgetItem support comparison.


4. Silencing mypy errors due to Qt's inherent design. Like a subclass 
providing a method whose signature is incompatible with the parent class 
method signature.


5. Some missing staticmethod decorators


6. Some missing imports for the stubs to be correct


7. Some method/function/decorators have such a complex usage that an 
advanced knowledge of mypy stub syntax is needed to annotate them 
correctly. That's the case for example for pyqtSlot and pyqtProperty


There are probably a few more but that gives you an idea of what we are 
talking about. Nowadays, we used some patching automation to fix the 
problems we are aware of for the stubs.


Out of the problem I described, item 1, 5 and 6 can certainly be fixed 
at the sip level. For all the others, there is not much to do except to 
apply blindly a better stub definition than what is currently available.


You can get a glimps of some of our fixes by looking at this file : 
https://github.com/python-qt-tools/PyQt6-stubs/blob/main/fixes/annotation_fixes.py#L74

For every FixParameter, the 3rd argument is the old annotation from 
PyQt6 and the 2nd is the annotation we want to put instead.


I am curious what you think of all this and if you want this to be 
contributed back to PyQt6 ?

Cheers,

Philippe




More information about the PyQt mailing list