You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
error: 'Union[Any, Tuple[Any, Any]]' object is not iterable #1855
fromtypingimport*Pair=Tuple[Any, Any]
deff(a: Union[Any, Pair]):
x, y=a# E: 'Union[Any, Tuple[Any, Any]]' object is not iterable
If the type of argument is either just Any or just Pair the code passes. But with the union it gives the error.
UPDATE: I don't think the unreduced union is at fault -- an example with two different Tuple types of length 2 also fails. It's more that the unpack operation isn't tried for each variant of the union.
Turns out it's not directly the same cause: the union case was not handled and not tested.
I believe it's the same root cause but in a deeper sense: the matching of multi-assignment and function calls define is typechecking and should be handled through the subtype module. Many subtype-related decisions are scattered through the checker (such as itemwise matching, and the iteration over union elements that I just added).
But even if it's not moved to subtype.py, I think it'll help to have a single matcher, common to function calls, multi assignment, multi-iteration (what's the terminology for that?) etc. If it was the case, my fix would have probably fixed #2128 too (I did not study it yet, though; It's just a guess).
Activity
gnprice commentedon Jul 14, 2016
We've seen this a couple of times internally.
elazarg commentedon Sep 18, 2016
Could be related to #2128 ?
gvanrossum commentedon Sep 18, 2016
elazarg commentedon Sep 18, 2016
Turns out it's not directly the same cause: the union case was not handled and not tested.
I believe it's the same root cause but in a deeper sense: the matching of multi-assignment and function calls define is typechecking and should be handled through the subtype module. Many subtype-related decisions are scattered through the checker (such as itemwise matching, and the iteration over union elements that I just added).
But even if it's not moved to
subtype.py, I think it'll help to have a single matcher, common to function calls, multi assignment, multi-iteration (what's the terminology for that?) etc. If it was the case, my fix would have probably fixed #2128 too (I did not study it yet, though; It's just a guess).nickpresta commentedon May 23, 2017
EDIT: I'm running mypy 0.511 -- I'm trying with the latest master now.
We're seeing this problem manifest itself with our code like this (no OSS code to link):
The error I get is:
The
Tuple[uuid.UUID, datetime.datetime, ...]bit is our Usernamedtuple.As soon as I do something like:
The error then goes away.
Right now we're working around it with the explicit index but any other insight would be much appreciated.
Thanks
gvanrossum commentedon May 23, 2017
Does it repro with the latest master?
nickpresta commentedon May 23, 2017
@gvanrossum I checked out master and tried to reproduce with
mypy 0.520-devand I don't get the error anymore.Thanks.
We will wait for
0.520to be published to PyPI.gvanrossum commentedon May 23, 2017
OK, then per our policy I will close this issue. (We close issues when they are fixed in master.)
ilevkivskyi commentedon May 23, 2017
But the original issue is not fixed, I just checked and I still see the same error:
'Union[Any, Tuple[Any, Any]]' object is not iterablegvanrossum commentedon May 23, 2017
Whoops, sorry.
Add comment explaining the status of RawConfigParser.items
Add comment explaining the status of RawConfigParser.items
Add comment explaining the status of RawConfigParser.items
Add comment explaining the status of RawConfigParser.items
Make configparser.RawConfigParser use SectionProxy where appropriate (#…
Allow assignments to multiple targets from union types (#4067)