Enable Mypy --strict internally

[michaeloliverx]

I think being compatible with mypy --strict benefits end users who are also using it, if #513 is merged then there isn't much work left to be compatible with strict mode.

See also #512

[michaeloliverx]

What do @encode/maintainers think of this?

[adriangb]

Would we do it only for the codebase or also for tests? The benefit of doing it for tests is that you get to asses what the experience would be like for a user in strict mode.

[adriangb]

I see you did both in your PR. I'm in favor of it 😁

[tomchristie]

Based on #524 I'd probably be somewhat against it - looks like extra noise & fluff from my perspective.

[michaeloliverx]

Would we do it only for the codebase or also for tests? The benefit of doing it for tests is that you get to asses what the experience would be like for a user in strict mode.

+1 for tests

I didn't type tests before I read this article https://sethmlarson.dev/blog/tests-arent-enough-case-study-after-adding-types-to-urllib3#type-your-tests which outlined the same benefit.

[michaeloliverx]

Based on #524 I'd probably be somewhat against it - looks like extra noise & fluff from my perspective.

I agree its quite a bit of noise.. another option would be to do it incrementally as files are changed?

[RA80533]

Based on #524 I'd probably be somewhat against it - looks like extra noise & fluff from my perspective.

Are there particular changes in the PR that you would rather see addressed separately, @tomchristie?

1. Narrowing # type: ignore to a particular class of error
2. Correcting incomplete dict and list types
3. Using type aliases on values with domain significance (HeadersAsMapping versus dict)
4. Casting types brought in from the h2 package

2. is the most important for the purpose of the PR. Each correction means one less error showing up to the user in VS Code and the like.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[graingert]

adding typing in anyio found a large number of type level bugs, I'm in favor of this change - so unmarking stale

[tomchristie]

I'm okay with us doing this, or at least with us moving towards it incrementally.
@michaeloliverx's work on #524 showed that it's quite a big change footprint.
I'd be happy to see PRs that either deal with changes on a one-module-at-a-time or one-kind-of-fix-at-a-time basis.

[adriangb]

I think we probably want to turn on --strict one file at a time right?

[tomchristie]

Yeah that sort of thing.
It'd probably be okay to make the fixes incrementally, without necessarily ratcheting them in using the CI.
We could improve them bit by bit and only hard-enforce it once we get there.

[tomchristie]

See encode/httpx#2436 for how I think we should approach this.