Making mypy happy

Running mypy on the current master branch, a lot of issues are found. I started fixing those issues in my fork. In the process, I already found 2 dormant bugs.

@Nick-Hall if you give me a :+1: that this is useful, I’ll complete it for the complete code base and open a PR in max. 2 weeks. The PR would also enable mypy checking as part of CI.

Note, I am not yet adding any type hints to existing code; only in ambiguous cases where mypy forces me to (e.g. empty dictionaries initialized in class constructors).

@Nick-Hall please let me know if you’d like me to continue working on this.

In my experience, having a codebase that passes mypy checks drastically reduces the amount of trivial (or dormant) bugs in new code contributions, so should be very helpful in refactoring such as the one being discussed in the performance thread.

I’ve posted to the gramps-devel mailing list for comments.

1 Like

One of the things that popped up - does somebody understand this line which instantiates the class with one argument too much? When is this code run?

PR created. Add mypy static type checker to CI and necessary fixes to the source code by DavidMStraub · Pull Request #1717 · gramps-project/gramps · GitHub