Is it time to introduce typing annotations?

[StSav012]

The oldest Python still supported by QtPy is 3.7. It has decent support for typing annotations. Still, the code of QtPy is merely typed. The typing of the code and the tests might further improve the code quality. So, this raises the question from the title: Is it time to introduce typing annotations, at least the ones supported by Python 3.7?

[dalthviz]

Hi! And yep it could be worthy, and probably we will also need to add a GitHub workflow to actually check the typings 🤔 Not sure how straightforward such an effort would be but happy to hear a plan to add typing annotations to the project code itself :)

[dalthviz]

Not sure what could be the best to be honest 🤔 What do you think @ccordoba12 @CAM-Gerlach ?

[ccordoba12]

It might be easier to check the code manually with something like mypy, i.e., as a workflow, it might be a check without a negative result

What do you mean by this @StSav012?

[StSav012]

I mean that mypy might sound an alarm because PySide6 stubs, for instance, are incomplete. I expect numerous false-positive warnings. Just run, say,

mypy --always-true=PYQT5 --always-false=PYSIDE2 --always-false=PYQT6 --always-false=PYSIDE6 qtpy/QtCore.py

and see for yourself. I've got 40 errors (and 67 errors with --strict) for the current qtpy/QtCore.py from the master branch. For the most of them, I don't see a way to avoid.

[dalthviz]

Maybe, as a first step, we could improve the typing in files with specific functions like qtpy/cli, qtpy/compat, qtpy/_utils, etc, while adding some CI workflow for validation but excluding other files which we already know will give false-positive warnings? I think we can add some mypy config to the setup.cfg to exclude files and further mark/ignore specific lines which could be triggering false-positives?

[ccordoba12]

I like both @dalthviz's suggestions: type simple files first and do this incrementally by excluding the other files, so we can add a MyPy check to our CIs.