-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Use format_type
for msg.type_not_iterable
#11490
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
Use format_type
for msg.type_not_iterable
#11490
Conversation
notes.append('Expression tuple item {} has type "{}"; "{}" expected; ' | ||
.format(str(i), format_type_bare(rhs_t), format_type_bare(lhs_t))) | ||
notes.append('Expression tuple item {} has type {}; {} expected; ' | ||
.format(str(i), format_type(rhs_t), format_type(lhs_t))) | ||
error_cnt += 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing from format_type_bare
to format_type
to keep consistency with other usage of format_type
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I have a couple of questions 🙂
@@ -1468,7 +1468,7 @@ x9, y9, x10, y10, z5 = *points2, 1, *points2 # E: Contiguous iterable with same | |||
() = [] # E: can't assign to () | |||
|
|||
[case testAssignEmptyBogus] | |||
() = 1 # E: "Literal[1]?" object is not iterable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a significant change and I don't think that is an improvement. Literal[1]
is more specific, I personally like it more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, this is an interesting case. I think it's a different issue that we might need to modify the format_type
.
@@ -556,7 +556,7 @@ reveal_type(d1) # N: Revealed type is "Union[Any, builtins.float]" | |||
reveal_type(d2) # N: Revealed type is "Union[Any, builtins.float]" | |||
|
|||
e: Union[Any, Tuple[float, float], int] | |||
(e1, e2) = e # E: "builtins.int" object is not iterable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a lot of places where builtins.
is used, and some places where it is not used. I cannot tell what kind of principle is used here 😞
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mypy
keeps the prefix in reveal_type
for more verbose information. And according to the original discussion, it's better to discard builtins.
to get concise error messages. Also, cpython dosen't output builtins.
when error occurs.
Closes python#5072, follows up to python#11490
Description
Related #5072
Uses
format_type
to get a more concise output.