Skip to content
New issue

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

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

Already on GitHub? # to your account

[red-knot] avoid inferring types if unpacking fails #16530

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

Conversation

mtshiba
Copy link
Contributor

@mtshiba mtshiba commented Mar 6, 2025

Summary

This PR closes #15199.

The change I just made is to set all variables to type Unknown if unpacking fails, but in some cases this may be excessive.
For example:

a, b, c = "ab"
reveal_type(a)  # Unknown, but it would be reasonable to think of it as LiteralString
reveal_type(c)  # Unknown
# Failed to unpack before the starred expression
(a, b, *c, d, e) = (1,)
reveal_type(a)  # Unknown
reveal_type(b)  # Unknown
...
# Failed to unpack after the starred expression
(a, b, *c, d, e) = (1, 2, 3)
reveal_type(a)  # Unknown, but should it be Literal[1]?
reveal_type(b)  # Unknown, but should it be Literal[2]?
reveal_type(c)  # Todo
reveal_type(d)  # Unknown
reveal_type(e)  # Unknown

I will modify it if you think it would be better to make it a different type than just Unknown.

Test Plan

I have made appropriate modifications to the test cases affected by this change, and also added some more test cases.

@AlexWaygood AlexWaygood added the red-knot Multi-file analysis & type inference label Mar 6, 2025
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[red-knot] Avoid inferring types in error case during unpacking
2 participants