Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Fix inference with UninhabitedType#16994

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@cdce8p
Copy link
Collaborator

@cdce8pcdce8p commentedMar 6, 2024
edited
Loading

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 resolvedict[str, int] anddict[Never, Never]. However in this case it's more reasonable to interpret the empty dict asdict[Any, Any] and just use the first type instead. That matches the behavior of pyright.

T=TypeVar("T")classA(Generic[T]): ...deffunc1(a:A[T],b:T)->T: ...defa1(a:A[Dict[str,int]])->None:reveal_type(func1(a, {}))
# beforemain: error: Cannot infer type argument 1 of "func1" (diff)main: note: Revealed type is "Any" (diff)# aftermain: note: Revealed type is "builtins.dict[builtins.str, builtins.int]"

@cdce8pcdce8p added the topic-inferenceWhen to infer types or require explicit annotations labelMar 6, 2024
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@cdce8p
Copy link
CollaboratorAuthor

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

T=TypeVar("T")classB(dict[T,T]): ...defa2(check:bool,a:B[str])->None:reveal_type(aifcheckelse {})
-Revealed type is "builtins.object"+Revealed type is "builtins.dict[builtins.str, builtins.str]"

TheNeed type annotation error is because now it's inferred asdict[Any, Any] instead ofobject. E.g. foralectryon

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.

@github-actions

This comment has been minimized.

Copy link
Collaborator

@hauntsaninjahauntsaninja left a comment
edited
Loading

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 Neverdef 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
CollaboratorAuthor

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 Neverdef 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 withNever /NoReturn. My lastcommit should address that.

@github-actions
Copy link
Contributor

Diff frommypy_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

@hauntsaninjahauntsaninja left a comment

Choose a reason for hiding this comment

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

Nice!

@hauntsaninjahauntsaninja merged commit2fbfb60 intopython:masterMar 7, 2024
@cdce8pcdce8p deleted the fix-inference-with-unihabited-type branchMarch 7, 2024 02:53
hauntsaninja added a commit to hauntsaninja/mypy that referenced this pull requestMay 31, 2024
Switches the logic frompython#16994to use ambiguous (since is_noreturn was only meant for error messages)See alsopython#15996
hauntsaninja added a commit that referenced this pull requestMay 31, 2024
Switches the logic from#16994 to useambiguous (since is_noreturn was only meant for error messages)See also#15996
GiorgosPapoutsakis pushed a commit to GiorgosPapoutsakis/mypy that referenced this pull requestJun 3, 2024
Switches the logic frompython#16994 to useambiguous (since is_noreturn was only meant for error messages)See alsopython#15996
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@hauntsaninjahauntsaninjahauntsaninja approved these changes

Assignees

No one assigned

Labels

topic-inferenceWhen to infer types or require explicit annotations

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@cdce8p@hauntsaninja

[8]ページ先頭

©2009-2025 Movatter.jp