PyQt6 stubs

[Phil Thompson]

On 03/08/2022 20:44, Philippe Fremy wrote:
> 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 ?

I suggest you review your list against the current version of PyQt6. 2, 
3 and 6 should be fixed.

Phil