Add mypy to the codebase

[ChrisLovering]

I'd like to propose that we add mypy to the codebase and add it to our linting workflow.

The initial PR for this would be a large one, fixing the legacy issues, but from then on it'll be picked up before a PR can even be merged.

There are stubs that we can add as dev dependencies for discord.py and any other deps that we find lacking in the type hinting department.

This issue is mostly for planning for now, as I'd like to get more opinions on this change.

[MarkKoz]

I've never given mypy a proper shot before. The one time I tried it I got a bad impression because I was immediately trying to do something it cannot support (defining a JSON type, which is recursive). It's left me with the impression that it may be a burden trying to appease mypy. Anyway, I am open to trying it.

My concern is the type stubs. Do all packages we use have type stubs? Are they all well maintained and up to date? What recourse do we have if something is lacking type stubs or falls out of date?

[TizzySaurus]

My concern is the type stubs. Do all packages we use have type stubs? Are they all well maintained and up to date? What recourse do we have if something is lacking type stubs or falls out of date?

To install all the known stubs we can do mypy --install-types. I can't remember from my testing how many this installs but it does install a few.

As for libraries without stubs, we can just not check those libraries by passing --disable-error-code import. We probably also want to ignore attribute errors since we have custom attributes like Logger.trace, which can be done with --disable-error-code attr-defined.

We'd also need to use the --namespace-packages flag so that p.e. discord.ext and discord.ext.commands are supported under the discord stub.

TLDR; The command I use for mypy on the bot currently is mypy bot --disable-error-code attr-defined --disable-error-code import --namespace-packages. I uploaded the output of this in #dev-contrib. The command can of course be further adjusted to our needs.

[decorator-factory]

What are the benefits of adding mypy to the CI?

[MarkKoz]

What are the benefits of adding mypy to the CI?

To ensure the code conforms to mypy. We can encourage contributors all we want, but ultimately we have no way to enforce that they run mypy before making commits. However, we do have control over CI, so that's where we can enforce it.

[decorator-factory]

To ensure the code conforms to mypy

Of course, that's what adding mypy to the CI does. But why do we want the code to strictly conform to mypy? That was my question

[MarkKoz]

To ensure the code conforms to mypy

Of course, that's what adding mypy to the CI does. But why do we want the code to strictly conform to mypy? That was my question

How do you use mypy? Is there some middle ground between not using it at all and enforcing it in CI? Or are you instead asking why we should be using mypy in any capacity?

[decorator-factory]

Or are you instead asking why we should be using mypy in any capacity?

Yes, that's what I'm asking. As you mentioned, mypy isn't perfect, and there are issues like missing/outdated/poor type stubs, which could be an obstacle. Therefore I'm asking what benefits it would bring so we can evaluate the pros vs cons.