Is pyright actually helping?

[CompRhys]

I said that I would go through a fix some of the linting issues a few weeks back but there are so many pointless pyright complaints that result in # type: ignore needing to be added everywhere that it makes me question whether there's a benefit to using pyright if the API is so complex that adhering to the type pyright rules becomes an additional burden even for correct code.

[jduerholt]

@bertiqwerty , what do you think?

[bertiqwerty]

hmm... not sure. Can we deactivate the rules where Pyright is really wrong? I think we do not do a very accurate job regarding the types in BoFire. Maybe, there is some potential to improve. Can you give some examples, @CompRhys?

[CompRhys]

My main issue with pyright is that there's no good way I can see to get it to run in pre-commit due to needing to install the package in the pre-commit env which I can't find a good solution for. As such it's something that will continually break because people "know" that their code works and so for development velocity often it makes sense to merge and fix later.

There are also weird redefinition choices that I needed to add in #505

[bertiqwerty]

Just for my understanding, do you think Pyright as a tool is not worth it or would you want to ditch static type checking altogether?

[CompRhys]

Unless there's not a good way to get the tool to work locally in the same way as in CI my thoughts are it's an annoyance rather than a benefit, cf just using a ruff rule to say you have to include type hints (without a checker). In the linked PR i fixed all the pyright issues I get locally pinning the pyright version to 1.1.305 rather than using the newer versions but it still seemingly divergences due to py3.10 in CI and me using py3.12 locally. There are too many ways to use this particular tool in a manner than even fixing all issues locally it will break the linting CI.