Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable mypy's strict equality checks #12209

Merged
merged 6 commits into from
Sep 23, 2023
Merged

Conversation

hauntsaninja
Copy link
Contributor

@hauntsaninja hauntsaninja commented Aug 6, 2023

This would have caught an issue I had when writing #12204. In that PR I changed something from a list to a set, which caused comparisons to other lists that previously held true to no longer hold. With this option enabled, mypy will complain about comparing something that's always a set to something that's always a list

This would have caught an issue I had when writing
pypa#12204
@@ -36,11 +36,14 @@ per-file-ignores =

[mypy]
mypy_path = $MYPY_CONFIG_FILE_DIR/src

strict = True
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I change to setting strict=True and opting out of specific checks.

This effectively enables strict_equality = True and a couple other options that have less of a bearing on the pip codebase. See also https://mypy.readthedocs.io/en/stable/existing_code.html#introduce-stricter-options

os.unlink,
os.remove,
os.rmdir,
): # type: ignore[comparison-overlap]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only annoying false positive

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is causing the false positive? I’m wondering if we should rewrite this or annotate the code better instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you annotate with Callable, mypy won't complain. I've pushed this change to the PR.

(I generally don't recommend use of types.FunctionType as an annotation, but in this instance it seems fine and mypy should have accepted the code as is)

Copy link
Member

@DiddiLeija DiddiLeija left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great! Also, I guess this would resolve #10076, an issue we left a while back?

Comment on lines +49 to +51
ResolverVariant = Literal[
"resolvelib", "legacy", "2020-resolver", "legacy-resolver"
]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be better to modify the code paths to enforce the "resolvelib" and "legacy" values consistently instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made this change locally, but I'm a little less sure of it. Maybe better to do in a separate PR?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool! As long as you don't forget to file it. 🙃

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a deal

@cclauss
Copy link
Contributor

cclauss commented Sep 6, 2023

I think we should move the running of mypy out of pre-commit because there are a lot of subtle complexities as discussed at:

Should we run mypy in a GitHub Action instead?

In any case, given that setup.cfg has been replaced by pyproject.toml, this PR will need to be rebased.

@hauntsaninja
Copy link
Contributor Author

hauntsaninja commented Sep 7, 2023

Yes, I also don't recommend using pre-commit with mypy, see this summary I wrote up: python/mypy#13916. But I'm pretty laissez fair, trying to focus on functional changes here!

Can this be merged? I promise I'll follow up with a PR for #12209 (comment) as soon as it is cc @pradyunsg

@hauntsaninja
Copy link
Contributor Author

The same test is failing on e.g. #12264

@hauntsaninja
Copy link
Contributor Author

master is green right now, so I merged and now this PR is also green again!

@pradyunsg pradyunsg merged commit eddd9dd into pypa:main Sep 23, 2023
24 checks passed
@hauntsaninja hauntsaninja deleted the mypy-strict branch September 24, 2023 00:25
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants