You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
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.
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.
Activity
michaeloliverx commentedon Mar 30, 2022
What do @encode/maintainers think of this?
adriangb commentedon Mar 30, 2022
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 commentedon Mar 30, 2022
I see you did both in your PR. I'm in favor of it 😁
lovelydinosaur commentedon Mar 30, 2022
Based on #524 I'd probably be somewhat against it - looks like extra noise & fluff from my perspective.
michaeloliverx commentedon Mar 30, 2022
+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 commentedon Mar 30, 2022
I agree its quite a bit of noise.. another option would be to do it incrementally as files are changed?
RA80533 commentedon Apr 24, 2022
Are there particular changes in the PR that you would rather see addressed separately, @tomchristie?
# type: ignoreto a particular class of errordictandlisttypesHeadersAsMappingversusdict)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 commentedon May 31, 2022
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 commentedon Jun 19, 2022
adding typing in anyio found a large number of type level bugs, I'm in favor of this change - so unmarking stale
lovelydinosaur commentedon Oct 7, 2022
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 commentedon Oct 7, 2022
I think we probably want to turn on
--strictone file at a time right?lovelydinosaur commentedon Oct 7, 2022
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.
lovelydinosaur commentedon Nov 17, 2022
See encode/httpx#2436 for how I think we should approach this.