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
Improve message when an annotation is expected #2463
Comments
If the type checking target is 3.6+ we should propose a non-comment annotation. Suggestion: x = Queue() # Need type annotation for variable (hint: "x: Queue[<type>] = ...")
x = [] # Need type annotation for variable (hint: "x: List[<type>] = ...") Another idea is to add a note about why this is needed or a pointer to documentation: a.py:3: error: Need type annotation for variable (hint: "x: Queue[<type>] = ...")
a.py:3: note: See also http://mypy.readthedocs.io/en/latest/common_issues.html#types-of-empty-collections (We might want to use a URL shortener or other ways of supporting shorter URLs in error messages.) |
I think adding a link to docs is unnecessarily verbose. It will help solve the problem the first time someone using mypy experiences it, but afterwards it doubles the length of the message without adding information. It would require maintaining all the URLs for docs, too. |
I'm working on this one. |
Fixes #2463 Improve error message when partial types are found for built-in types `Dict`, `List`, `Set`, `FrozenSet`. Messages used to be like: ``` main:3: error: Need type annotation for 'x' ``` This PR modifies it to look like: ``` main:3: error: Need type annotation for 'x' (hint: "x: List[<type>] = ...") ``` In case the variable is not of a built-in type the hints are not shown.
To be honest, I'm not 100% sure if my PR solved completely this issue. I say that because I don't cover custom types. I don't know if custom types hints are still in the scope of this issue. Any thoughts @JukkaL ? |
I think custom types are much more rare, so this is not super important but is still good to have. For custom types I would also add the note with the link to the docs as suggested above. You can probably do these things in an additional PR. |
Maybe you can create a follow-up issue for custom type support? I agree that this is less important since new users will almost certainly first encounter one of the builtin collections, and after they've learned how to annotate them, I expect that it will be easy to apply to user-defined types as well (but I may be wrong there). |
I agree with @JukkaL here. When people get to the point they are creating custom types, it is likely they know how to annotate. Also thinking of balance of difficult to implement and usefulness I believe expanding hints for that will not be so simple to implement. Therefore I think it's not worth to expand to that point for now. Maybe if someone finds a specific scenario where the hints could be expanded for custom types, they can open a new ticket. |
In cases like this, the current error message isn't as helpful as it could be:
Here's an idea for a better message:
We could recognize the common case where the initializer constructs a generic instance and there is not enough information to infer all the type arguments. For other cases we can fall back to the current message.
The idea came from @aleksanb on gitter.
The text was updated successfully, but these errors were encountered: