PyQt6 snapshots just came out. Currently they're nothing more than PyQt5 with some deprecated features removed. But it begs the question: will PyQt5-stubs support PyQt6?

Hi,

Maybe this is not the right place to ask, if so thanks to redirect me...

Code:

from PyQt5.QtWidgets import QDialog
from PyQt5.QtCore import QObject

a = QDialog()
b = a.result()  # ok inferred type int
c = a.qsdf()  # should be error missing method but inferred type is any
d = a.isWidgetType()  # method of QObject, parent class of QDialog, a bool should be inferred but inferred tye is any

e = QObject()
f = e.isWidgetType()  # ok inferred type bool

class G:
    def yo(self) -> str:
        return "yo"

class H(G):
    pass

i = H()
j = i.yo()  # ok inferred type str
k = i.qsdf()  # ok error no attribute

reveal_locals()

mypy output is:

27:5: error: "H" has no attribute "qsdf"
29:1: note: Revealed local types are:
29:1: note:     a: PyQt5.QtWidgets.QDialog
29:1: note:     b: builtins.int
29:1: note:     c: Any
29:1: note:     d: Any
29:1: note:     e: PyQt5.QtCore.QObject
29:1: note:     f: builtins.bool
29:1: note:     i: test_module.H
29:1: note:     j: builtins.str
29:1: note:     k: Any

The question is: why does mypy does not detect these errors with PyQt objects?

I am using version 5.11.3.0 of PyQt5-stubs

Thanks

Thanks to @BryceBeagle we now have much more stubs to offer. I didn't have a closer look at them. But I guess they also need to be altered to be usable with mypy.

I have created the PyQt5-stubs to add proper type annotations mainly for my personal PyQt5 applications without thinking much about a future-proof update strategy. It turns out that it is very cumbersome to take care of any version changes and keep the whole thing up-to-date with the upstream PyQt5 repository. Additionally I find myself using PySide2 more and more. PySide2 provides proper type annotations out of the box and has a more open licensing model. Because of this I decided to stop maintaining this package in the future. However, I would love to find a new maintainer that keeps this package alive. So if someone likes to take care of this package please contact me.

Before the fix, the test would report:

windowflags.py:10: error: Incompatible types in assignment (expression has type "int", variable has type "WindowType")
windowflags.py:18: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:19: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:20: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:21: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:22: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:27: error: Unsupported operand types for + ("WindowFlags" and "WindowType")
windowflags.py:27: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:28: error: Unsupported operand types for - ("WindowFlags" and "WindowType")
windowflags.py:28: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:29: error: Unsupported operand types for | ("WindowFlags" and "WindowType")
windowflags.py:29: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:30: error: Unsupported operand types for & ("WindowFlags" and "WindowType")
windowflags.py:30: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:31: error: Unsupported operand types for ^ ("WindowFlags" and "WindowType")
windowflags.py:31: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:34: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:34: error: Unsupported operand types for + ("WindowType" and "WindowFlags")
windowflags.py:35: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:35: error: Unsupported operand types for - ("WindowType" and "WindowFlags")
windowflags.py:36: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:36: error: Unsupported operand types for | ("WindowType" and "WindowFlags")
windowflags.py:37: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:37: error: Unsupported operand types for & ("WindowType" and "WindowFlags")
windowflags.py:38: error: Incompatible types in assignment (expression has type "int", variable has type "WindowFlags")
windowflags.py:38: error: Unsupported operand types for ^ ("WindowType" and "WindowFlags")
windowflags.py:41: error: Unsupported left operand type for + ("WindowFlags")
windowflags.py:42: error: Unsupported left operand type for - ("WindowFlags")
windowflags.py:43: error: Unsupported left operand type for | ("WindowFlags")
windowflags.py:44: error: Unsupported left operand type for & ("WindowFlags")
windowflags.py:45: error: Unsupported left operand type for ^ ("WindowFlags")

Here's a draft pull request for a Dockerfile to build the upstream stubs, along with the new/updated stubs. Some existing stubs receive new annotations to work data types from the new stubs.

There's also a build script (build_upstream.py) that handles building the image and extracting the files to the host.

Some things worth discussion:

• No idea how to build only stubs with the new sip-install command. The stubs are all generated at the beginning of the PyQt build and then I have to wait for it to finish. I'm sure there's a way I could kill the build early, but I didn't bother.
• I'm unable to build QtAxContainer, QtAndroidExtras, QtMacExtras, and QtWindowsExtras in Docker, to my understanding
• Even though I install their dependencies, I'm missing stubs for the following. Maybe they don't generate?
  • Qt3d
  • QtCharts
  • QtDataVisualization
  • QtPurchasing
  • QtWebEngine
  • Enginio (deprecated so probably doesn't matter)

For reference: all the modules that PyQt supports: https://www.riverbankcomputing.com/static/Docs/PyQt5/module_index.html#ref-module-index

I understand that it is quite cumbersome to track all the releases (major and minor) of PyQt5 and keep this stub package up-to-date from a pip dependency point of view.

However, if you think about it :

• all versions of PyQt5 and Qt5 are backward compatible.
• so, a stub file valid for PyQt 5.13 will also be useful and valid for 5.12 . Maybe there are a few extra methods but that's a small issue
• also, a stub file valid for PyQt 5.13 is certainly useful and valid for PyQt 5.14 and 5.15 . Same story, a few new methods or objects could be missing but that's about 0.01% of the codebase.

So my suggestion : declare PyQt5 5.* as a dependency.

This means that basically every user of PyQt5 can take advnatage of the stubs, whatever the version he is using. It means more potential contributors !

Hi,

Thanks for the great work on PyQt5 stubs, it is a pleasure to use it.

In my code, I often disable the annoying help button of the window bar with the following code dialog.setWindowFlags(dialog.windowFlags() & ~Qt.WindowContextHelpButtonHint)

Mypy fails on it with : src\mg_dialog_run_git_cmd.py:29: error: Unsupported operand types for & ("WindowFlags" and "int")

I am trying to enhance type checking for this case. There are actually two issues :

• Qt.WindowType (the class of Qt.WindowContextHelpButtonHint) is not typechecked for the operator ~
• Qt.WindowFlags (the class of dialog.windowFlags()) is not typechecked for the operator &

I have "implemented" the solution by annotating additional operations for both types. Is it something worth adding to the official stubs ?

I started from my work on windowFlags and look for ways to make it generic. I failed at defining a generic approach with mypy, protocols and generics inheriting from int, it is really above my understanding of mypy.

But, it's easy enough to generate a file for each QFlag based class which can be used to assert both the actual implementation types and values, and which ensures that the class is being correctly checked. This is what I am doing here for two classes : WindowFlags and Alignment.

With a few more hours, I should be able to cover all qflags based class. This would remove a big hole in PyQt stubs.

According to the PyQt mailinglist, the next PyQt release will ship wheels with its own stubs:

https://www.riverbankcomputing.com/pipermail/pyqt/2020-April/042854.html

My first thought was "hey, cool, so we don't need to build anything to get the stubs files!" (cc @BryceBeagle)... However, my second thought was "wait a minute... what will happen when people have both PyQt5 and PyQt5-stubs installed"? No idea which of the two will take precedence then, even after reading the relevant part of the PEP I don't understand what precedence stubs as part of the installed package (i.e. not inline types) have...

This code seems to fail with the stubs:

QMessageBox.question(self, "Confirm", "Are you sure?", QMessageBox.Yes | QMessageBox.No)

Tells me:

Argument 4 to "question" of "QMessageBox" has incompatible type "int"; expected "Union[StandardButtons, StandardButton]"

But the code should work, should it not?

Hi,

Now that the PyQt5 stubs are released as part of PyQt5 pypi package, do we really need to keep this build process in place ?

A few facts :

• the build process is not documented. For somebody not familiar with docker, it might be difficult to grab. Adding a proper section in doc/developer_guide.md would be a very good idea
• last time I checked, the pyi coming from the stubs are really the same as the one generated from the build process. I'll double-check that point though.
• this build process is linux centric and fails to capture the specifics of the pyi for each platform. This won't be addressed in this issue directly but downloading the pyi from the different platforms allows us to capture the specifics of each platform

@The-Compiler shared in an email that PyQtWebkit pyi generation depends on the Docker file for its stubs generation. However, the Docker file does not contain anything related to PyQtWebkit and PyQt5 does not ship QtWebkit modules.

So, I am under the impression that the Docker file can be removed because pyi provides the same services.

For QtWebkit, if it's not shipped with PyQt5, it might be a good idea to create a dedicated stub project file on pypi (PyQtWebkit-stubs) else people are unlikely to find the corresponding stubs.

after I upgrade to pyqt5-stubs version 5.15.2.0, the XXX.clickked.XXX 's autocompletion in pycharm(2021.1) didn"t work.But in Vscode(with pylance) it works well.Then i downgrade to pyqt5-stubds version 5.14.2.2 ,the XXX.clickked.XXX 's autocompletion in pycharm(2021.1) starts working.

Steps

Install PyQt5 package and type the import statement: from PyQt5 import QtGui, uic PyCharm will offer to install PyQt5-stubs. Agree. Actual - uic submodule is marked as unresolved. The code runs.

Reported to JetBrains, and listed as an issue: https://youtrack.jetbrains.com/issue/PY-47685

"self.scroll_area = QtWidgets.QScrollArea(widgetResizable=True)"

generates following error message:

error: Unexpected keyword argument "widgetResizable" for "QScrollArea"