-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Closed
Labels
tyMulti-file analysis & type inferenceMulti-file analysis & type inference
Milestone
Description
This is probably not a high-priority feature, but it would be great if we could detect attribute assignments in unreachable code sections, and eliminate them from the set of possible answers:
class C:
def __init__(self) -> None:
if True:
self.x = 1
else:
self.x = "a"
return
self.y = "unreachable"
reveal_type(C().x) # should be `Unknown | Literal[1]` (i.e. not include `Literal["a"]`)
# Should be an error:
C().yNote that we have one existing test for this here:
ruff/crates/red_knot_python_semantic/resources/mdtest/attributes.md
Lines 434 to 448 in 16f2a93
| ```py | |
| class C: | |
| def __init__(self) -> None: | |
| # We use a "significantly complex" condition here (instead of just `False`) | |
| # for a proper comparison with mypy and pyright, which distinguish between | |
| # conditions that can be resolved from a simple pattern matching and those | |
| # that need proper type inference. | |
| if (2 + 3) < 4: | |
| self.x: str = "a" | |
| # TODO: Ideally, this would result in a `unresolved-attribute` error. But mypy and pyright | |
| # do not support this either (for conditions that can only be resolved to `False` in type | |
| # inference), so it does not seem to be particularly important. | |
| reveal_type(C().x) # revealed: str | |
| ``` |
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
tyMulti-file analysis & type inferenceMulti-file analysis & type inference