Closed FichteFoll closed 7 years ago
Two new versions of mypy have since been released. I still have to check whether we can put something from those to use or whether accuracy has improved. I did get a few pull requests to typeshed merged, however.
I experimented with mypy a bit. It seems to be a lot more mature now than when I last tried it, so I went ahead and enable a couple options to see how much boilerplate we'd have to add.
This PR passes mypy with the strictest settings I could find, even though I only enabled the less strict checks for CI and the normal runtime config.
We were using type annotations previously, but inconsistently and did not check them at all. They were only for cosmetical reasons. With the tooling now being in a workable state, the question now becomes:
Any
acceptable in cases where we don't want to bother?The commits in this PR are iterative. Over time I enabled more and more options that I adjusted the code base to pass. Maybe you feel like we should stop after some specific commit? Personally, I haven't really made up my mind about this.
Either way, due to this PR modifying almost every function signature, it should be (partially) merged or rejected before working on other features due to the high probability of creating merge conflicts.
Here's the related PEP for reference https://www.python.org/dev/peps/pep-0484/.