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.

[jduerholt]

@bertiqwerty: what do you think about using such a ruff rule to enforce that the user actually uses types?

[bertiqwerty]

In general, I am in favor of correct type hints. So I am still not sure what to do. Just a few temporary thoughts:

• Just saying that there have to be type hints will probably lead to a lot of wrong type hints, Is this better than no type hints?
• We could lint in the pipeline only e.g., the latest supported Python version. Then, the problem of different results with different Python versions should be less of an issue.
• There are other tools like Mypy. Maybe they are easier work with. BayBE for instance uses Mypy.
• Locally, I wouldn't necessarily want to integrate the type checker as a pre-commit-hook. Rather have it as plugin in my IDE to check the types already while typing.

I have to think about this. In the meantime, let's get some more opinions. @LukasHebing, @WaStCo, @R-M-Lee, @sleweke-bayer, what do you think?

[LukasHebing]

I am also a fan of correct typing (@bertiqwerty). But with pyright, I had several problems:

• I couldn`t reproduce the behavior locally
• A lot of fails were actually wrong (code worked as it should, with the given types)
• For some reformulations (same line of code), it took me hours to find the "pyright-correct" version. Very annoying.

However, in some places, it was helpful, e.g. to think about optional, None inputs that I forgot to test.

[bertiqwerty]

For some reformulations (same line of code), it took me hours to find the "pyright-correct" version. Very annoying.

Can you show some examples?