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

Fix inference with UninhabitedType #16994

Merged

Conversation

cdce8p
Copy link
Collaborator

@cdce8p cdce8p commented Mar 6, 2024

At the moment, inference fails if an empty dict is used (without annotation) as one of the types. It's because the constraint solver can't resolve dict[str, int] and dict[Never, Never]. However in this case it's more reasonable to interpret the empty dict as dict[Any, Any] and just use the first type instead. That matches the behavior of pyright.

T = TypeVar("T")
class A(Generic[T]): ...

def func1(a: A[T], b: T) -> T: ...

def a1(a: A[Dict[str, int]]) -> None:
    reveal_type(func1(a, {}))
# before
main: error: Cannot infer type argument 1 of "func1" (diff)
main: note: Revealed type is "Any" (diff)

# after
main: note: Revealed type is "builtins.dict[builtins.str, builtins.int]"

@cdce8p cdce8p added the topic-inference When to infer types or require explicit annotations label Mar 6, 2024

This comment has been minimized.

This comment has been minimized.

@cdce8p
Copy link
Collaborator Author

cdce8p commented Mar 6, 2024

The primer output looks good! There are a few examples where this change allows for better generic type inference.
E.g. for prefect, it's something like this

T = TypeVar("T")

class B(dict[T, T]): ...

def a2(check: bool, a: B[str]) -> None:
    reveal_type(a if check else {})
-Revealed type is "builtins.object"
+Revealed type is "builtins.dict[builtins.str, builtins.str]"

The Need type annotation error is because now it's inferred as dict[Any, Any] instead of object. E.g. for alectryon

c = {1: {}, 2: {"key": {}}}
reveal_type(c)
-Revealed type is "builtins.dict[builtins.int, builtins.object]"
+Revealed type is "builtins.dict[builtins.int, builtins.dict[builtins.str, builtins.dict[Any, Any]]]

--
I've added additional test cases for these.

This comment has been minimized.

@cdce8p cdce8p requested a review from hauntsaninja March 7, 2024 00:06
Copy link
Collaborator

@hauntsaninja hauntsaninja left a comment

Choose a reason for hiding this comment

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

Thanks! Clearly empirically good.

I'm a little unsure about whether this is theoretically good, since it's icky to merge different types in an invariant context.

from typing import Never

def foo(x: list[str], y: list[Never]):
    reveal_type([x, y])  # now shows list[list[str]]
    o = [x, y]
    o[1].append("asdf")  # list[Never] now contains a str, this may surprise caller of foo

I think I'm still in favour of merging, but maybe we should have^ as a test

@cdce8p
Copy link
Collaborator Author

cdce8p commented Mar 7, 2024

I'm a little unsure about whether this is theoretically good, since it's icky to merge different types in an invariant context.

from typing import Never

def foo(x: list[str], y: list[Never]):
    reveal_type([x, y])  # now shows list[list[str]]
    o = [x, y]
    o[1].append("asdf")  # list[Never] now contains a str, this may surprise caller of foo

If it's just this edge case with Never / NoReturn. My last commit should address that.

Copy link
Contributor

github-actions bot commented Mar 7, 2024

Diff from mypy_primer, showing the effect of this PR on open source code:

steam.py (https://github.com/Gobot1234/steam.py)
- steam/ext/commands/commands.py:589: error: Incompatible types in assignment (expression has type "object", variable has type "dict[str, Command[CogT, [VarArg(Any), KwArg(Any)], Any]]")  [assignment]

comtypes (https://github.com/enthought/comtypes)
- comtypes/tools/tlbparser.py:443: error: Incompatible return value type (got "object", expected "list[str]")  [return-value]

prefect (https://github.com/PrefectHQ/prefect)
- src/prefect/infrastructure/process.py:243: error: Unpacked dict entry 0 has incompatible type "object"; expected "SupportsKeysAndGetItem[str, str | None]"  [dict-item]

jax (https://github.com/google/jax)
+ jax/_src/numpy/lax_numpy.py:1798: error: Unused "type: ignore" comment  [unused-ignore]

alectryon (https://github.com/cpitclaudel/alectryon)
+ alectryon/markers.py:100: error: Need type annotation for "QUERY_SHAPE"  [var-annotated]

mkdocs (https://github.com/mkdocs/mkdocs)
+ mkdocs/tests/config/config_options_tests.py:1597: error: Need type annotation for "cfg"  [var-annotated]

Copy link
Collaborator

@hauntsaninja hauntsaninja left a comment

Choose a reason for hiding this comment

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

Nice!

@hauntsaninja hauntsaninja merged commit 2fbfb60 into python:master Mar 7, 2024
18 checks passed
@cdce8p cdce8p deleted the fix-inference-with-unihabited-type branch March 7, 2024 02:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-inference When to infer types or require explicit annotations
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants