-
-
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
Unpacking an iterable in a list comprehension leads to the type inferred as list[Any] #15747
Comments
I'll give it a try. |
Are you still working on it? I can give it a try as well. Any insights to the issue? |
@JaylenLuc Please feel free to pick it up. I couldn't come up with a solution to it. What I got is that in the example posted in the issue, Lines 1660 to 1687 in 9e1f4df
|
working on it. made progress, ill get back to you with my findings |
preface: I'm a first time open source contributor :) In the infer_constraints_for_callable() function in constraints.py it calls infer_constraints() towards the end of the function which produces "[1 :> Any]" when it should produce: "[1 :> builtins.int]". It may be because of a previous function call not far before it in the same function called mapper.expand_actual_type() that produces "Any" instead of builtins.int. This may be because its first argument "actual_arg_type" may be incorrect. Why I say this is because "actual_arg_type" is "Spam " when i think it should be "typing.Iterator[builtins.int]" or typing.generator[builtins.int]. The aforementioned "actual_arg_type" is infer_constraints_for_callable()'s second positional argument : "arg_types: Sequence[Type | None]". This argument is supplied by infer_function_type_arguments as "arg_types" in infer.py which is called by another function of the same name in checkexpr.py. The erroneous type (Spam instead of builtins.generator) is supplied by infer_arg_types_in_context() called in the same function before in infer_function_type_arguments(). This infer_arg_types_in_context() function calls accept which actually interprets the type correctly when it calls visit_int_expr() defined in checkexpr.py which calls infer_literal_expr_type() also defined in checkexpr.py. I dont know what is causing the arg_types parameter to be Spam instead of int in infer_function_type_arguments in infer.py. This may be a problem that has to do with Python instead of MyPy but I have no clue. But it may not because Python actually knows what the yield type of generators are when you use the builtin : type() function on *a ( type(*a) --> <class 'int'>) Should the generator unpacking expression that is erroneous be a mypy.nodes.NameExpr instead of mypy.nodes.NameExpr? How do you all reckon about this issue? @hauntsaninja @kamilturek @hvenev |
im trying to figure out how the * unpacking unary operator works. is [*a.iter()] the same as reveal_type([*a])? |
I didn't understand that comment, but my guess is you'd need to trace the code into argmap.py |
|
in checkexpr.py, the function infer_arg_types_in_context() on line 1985 returns [testing.Spam] when it should return typing.Iterator[builtins.int]. Lines 1984 to 2008 in 8b73cc2
This testing.Spam object is an Instance object where testing.Spam.args length is 0. This means that MyPy thinks testing.Spam has no arguments when it checks in argmap.py line 192 and returns AnyType(TypeOfAny.from_error) on line 217 instead of the result from map_instance_to_supertype(). Lines 191 to 219 in 8b73cc2
The main issue is that [*a] cannot be unpacked and thus the types of what the Spam object yields is not unpacked. how do you all reckon? |
Yeah, I'm guessing that code dates back before structural types and Protocols. Probably want to swap out the stuff in argmap for some code from checker that analyses the return type of |
submitted a PR. if you check the PR comment I made, the only issues I'm having are with dmypy_server.py which is strange since I don't know how my changes are affecting it. |
I think #14470 reports the same thing as well |
And I'm not sure if my quite naive attempt in #14496 could provide any additional insights in how to resolve the issue (or if it resolves the repro case found here) |
Bug Report
When a value of a user-defined class with
__iter__
is converted into a list using[*value]
, the type of the list is inferred aslist[Any]
.To Reproduce
Expected Behavior
The type of
[*a]
islist[int]
Actual Behavior
Your Environment
--strict
mypy.ini
(and other config files):3.11.4
The text was updated successfully, but these errors were encountered: