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

Require an annotation if inferred list or dict item type is object #3816

Open
JukkaL opened this issue Aug 9, 2017 · 12 comments
Open

Require an annotation if inferred list or dict item type is object #3816

JukkaL opened this issue Aug 9, 2017 · 12 comments
Labels
topic-join-v-union Using join vs. using unions topic-usability

Comments

@JukkaL
Copy link
Collaborator

JukkaL commented Aug 9, 2017

Mypy infers the type List[object] for x in this example:

x = [1, 'a']

This is often not what the user expects and can be confusing, as there tends to be an error when the program tries to do something with the list. Often the user would prefer the type to be List[Any] or List[Union[int, str]], but generally the desired item type could be something else, such as an ABC or protocol (once protocols are supported).

It's perhaps impractical to unambiguously infer the desired type, but it would be easy enough to detect cases like these and require an explicit annotation. For the above example, mypy would require an annotation for x (and potentially suggest List[Any] or List[Union[int, str]] as the potential type), similar to how mypy deals with x = [].

For user-defined generic types object might be a reasonable value for a type parameter, so we should probably restrict this to things where the object type is likely a problem. For example, we could generate the message for the types List[object] and Dict[<anything>, object] only. It's less clear if we should do this for dictionaries withobject keys or for sets.

@JukkaL
Copy link
Collaborator Author

JukkaL commented Feb 8, 2018

#4548 has relevant discussion.

@JukkaL
Copy link
Collaborator Author

JukkaL commented Feb 19, 2018

Marking as high priority since this seems to be a common source of confusion.

@ilevkivskyi ilevkivskyi self-assigned this Feb 21, 2018
@ilevkivskyi ilevkivskyi removed their assignment May 14, 2018
ilevkivskyi added a commit that referenced this issue Oct 22, 2018
Fixes #2035

Note that in two tests we now infer `object` instead of giving an error. This may be not what a user expects, but I think this is still OK, and after #3816 mypy will always ask for an annotation in such cases.
@jxcl
Copy link
Contributor

jxcl commented May 7, 2019

Working on this.

@gvanrossum
Copy link
Member

Should this require a flag to enable it? (Or perhaps allow a flag to disable it?)

@jxcl
Copy link
Contributor

jxcl commented May 7, 2019

I'm in support of a flag to disable. It is a backwards incompatible change, but no heavy refactoring is required to fix existing code, only taking the inferred types that the mypy errors generate and applying them to the codebase.

Disabling by default would not fix the issue of new users being confused by the inference, since they would also presumably not know about the flag.

@JelleZijlstra
Copy link
Member

#6805 has a similar example where we unexpectedly infer Dict[str, int] for essentially {"a": 1, "b": True}.

@ilevkivskyi
Copy link
Member

It would be great to sometimes suggest using TypedDict, but such cases are very hard to identify.

@DevilXD
Copy link

DevilXD commented Mar 3, 2020

Is this ever gonna be a thing?

@JukkaL
Copy link
Collaborator Author

JukkaL commented Jun 8, 2020

We might want to also do this for sets (#8947).

Also, there will need to be a way to disable this, but not enabling this by default would be a bit pointless, as discussed above.

@ChetanKhanna
Copy link
Contributor

Hi! I had been looking at this issue and the PR #6792 that's already opened for it. Since there is no activity on the PR for over a year, can I start a new one from where it left? I believe what's remaining is to fix broken test cases and add a few new ones? I'll try to make it work for sets and the optional flag as discussed above.

@JukkaL
Copy link
Collaborator Author

JukkaL commented Jun 19, 2020

@ChetanKhanna Sure, feel free to continue working on it!

ChetanKhanna added a commit to ChetanKhanna/mypy that referenced this issue Jun 26, 2020
This PR does the following:
- Fixes failing tests from PR 6792
- Adds suugested annotation note
- Adds annotation checker for sets
- Adds tests
@ChetanKhanna
Copy link
Contributor

I opened a PR for this: #9051

ChetanKhanna added a commit to ChetanKhanna/mypy that referenced this issue Oct 24, 2020
This PR does the following:
- Fixes failing tests from PR 6792
- Adds suugested annotation note
- Adds annotation checker for sets
- Adds tests
@JelleZijlstra JelleZijlstra added the topic-join-v-union Using join vs. using unions label Mar 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-join-v-union Using join vs. using unions topic-usability
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants