-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
No type narrowing for in
on dict.keys()
#13360
Labels
Comments
matthewhughes934
changed the title
No type narrowing for dict.keys()
No type narrowing for ìn`on dict.keys()
Aug 8, 2022
matthewhughes934
changed the title
No type narrowing for ìn`on dict.keys()
No type narrowing for Aug 8, 2022
in
on dict.keys()
matthewhughes934
changed the title
No type narrowing for
No type narrowing for Aug 8, 2022
in
on dict.keys()in
on dict.keys()
We know that |
AlexWaygood
added
feature
topic-type-narrowing
Conditional type narrowing / binder
and removed
bug
mypy got something wrong
labels
Aug 9, 2022
matthewhughes934
added a commit
to matthewhughes934/mypy
that referenced
this issue
Aug 9, 2022
This is to bring the following cases into alignment: key: str | None d: dict[str, str] if key in d: # type of 'key' is inferred to be 'str' ... if key in d.keys(): # type of 'key' should be inferred to be 'str' ... Before this change only the first `if` would narrow the type of `key`. GH: issue python#13360
matthewhughes934
added a commit
to matthewhughes934/mypy
that referenced
this issue
Aug 16, 2022
Also for containership checks on `typing.KeysView.` This is to bring the following cases into alignment: from typing import KeysView key: str | None d: dict[str, int] kv: KeysView[str] if key in d: # type of 'key' is inferred to be 'str' ... if key in d.keys(): # type of 'key' should be inferred to be 'str' ... if key in kv: # type of 'key' should be inferred to be 'str' ... Before this change only the first `if` would narrow the type of `key`. I've just added a test under `test-data/unit/pythoneval.test` as `test-data/unit/fixtures/dict.pyi` doesn't include `dict.keys`, and adding it requires importing `dict_keys` from `_collections_abc` in those stubs, which then requires adding `_collections_abc.pyi` stubs, which would have to be complete since e.g. `testGenericAliasCollectionsABCReveal` expects most of the types in those stubs to be defined (this is the same approach as 7678f28). GH: issue python#13360
matthewhughes934
added a commit
to matthewhughes934/mypy
that referenced
this issue
Aug 23, 2022
Also for containership checks on `typing.KeysView.` This is to bring the following cases into alignment: from typing import KeysView key: str | None d: dict[str, int] kv: KeysView[str] if key in d: # type of 'key' is inferred to be 'str' ... if key in d.keys(): # type of 'key' should be inferred to be 'str' ... if key in kv: # type of 'key' should be inferred to be 'str' ... Before this change only the first `if` would narrow the type of `key`. I've just added a test under `test-data/unit/pythoneval.test` as `test-data/unit/fixtures/dict.pyi` doesn't include `dict.keys`, and adding it requires importing `dict_keys` from `_collections_abc` in those stubs, which then requires adding `_collections_abc.pyi` stubs, which would have to be complete since e.g. `testGenericAliasCollectionsABCReveal` expects most of the types in those stubs to be defined (this is the same approach as 7678f28). GH: issue python#13360
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
A an
if
statement likeif x in some_dict.keys()
doesn't narrow the type ofx
to the type of the key ofsome_dict
.This is in contrast with
if x in some_dict
which does correctly narrow.(I had a search and didn't find a similar existing discussion, apologies if this isn't the case)
To Reproduce
Run
mypy
over the following:Expected Behavior
mypy
correctly narrows the type in each of theif
statements and the script passes.Actual Behavior
mypy
reports failures as:Your Environment
0.971
andmypy 0.980+dev.e69bd9a7270daac8db409e8d08400d9d32367c32 (compiled: no)
(currentmaster
)mypy <name-of-file-above>
mypy.ini
(and other config files): the above was run from the root of this project (so whatever's configured there)Python 3.10.5
The following allows
get_via_keys
above to pass undermypy
Though I'm not sure how appropriate it would be given the note in the docs for that function:
Also,
dict_keys
is undocumented and a quickgit grep --word-regexp 'dict_keys'
didn't show much usage for it outside oftypeshed
.The text was updated successfully, but these errors were encountered: