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

[red-knot] Check if callable type is fully static #16633

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

dhruvmanila
Copy link
Member

@dhruvmanila dhruvmanila commented Mar 11, 2025

Summary

Part of #15382

This PR adds the check for whether a callable type is fully static or not.

A callable type is fully static if all of the parameter types are fully static and the return type is fully static and if it does not use the gradual form (...) for its parameters.

Test Plan

Update is_fully_static.md with callable types.

It seems that currently this test is grouped into either fully static or not, I think it would be useful to split them up in groups like callable, etc. I intentionally avoided that in this PR but I'll put up a PR for an appropriate split.

Note: I've an explicit goal of updating the property tests with the new callable types once all relations are implemented.

@dhruvmanila dhruvmanila added the red-knot Multi-file analysis & type inference label Mar 11, 2025
Copy link
Contributor

github-actions bot commented Mar 11, 2025

mypy_primer results

No ecosystem changes detected ✅

Copy link
Contributor

@sharkdp sharkdp left a comment

Choose a reason for hiding this comment

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

This looks good, thank you.

May I ask why you plan to wait with the property tests until after you implemented all type properties? It seems to me like they could be of help. If you start out by returning false everywhere, they might even pass most existing property tests everywhere since they wouldn't fulfill the preconditions?

@dhruvmanila
Copy link
Member Author

May I ask why you plan to wait with the property tests until after you implemented all type properties? It seems to me like they could be of help. If you start out by returning false everywhere, they might even pass most existing property tests everywhere since they wouldn't fulfill the preconditions?

Not at all. My main reason was to independently put up PRs for each method and continue with the others without blocking the ones that are good to go and enabling property tests could create CI failures on main for the ones that haven't been implemented yet.

That said, I do use a default return value (mostly false) for the ones that haven't been implemented yet and I can try adding them to verify today. Thanks for the suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants