Unexpected error when creating a Dict from a list of lists len 2

[adamtheturtle]

I have the following code which works.

from typing import Dict

my_list = ['a', 'b']
my_dict: Dict[str, str] = dict([my_list])
print(my_dict)  # {'a': 'b'}

mypy gives the following error:

example.py:4: error: List item 0 has incompatible type "List[str]"; expected "Tuple[str, str]"

I expect that in this case mypy would not show an error because the code is valid.

From https://docs.python.org/3/library/stdtypes.html#dict:

Each item in the iterable must itself be an iterable with exactly two objects.

From python/mypy#6542 (comment) (@srittau):

Seems like a typeshed issue. Possibly dict.__init__() is missing an overload like:

    @overload
    def __init__(self, iterable: Iterable[Iterable[Union[_KT, _VT]]], **kwargs: _VT) -> None: ...

[ilevkivskyi]

There is no such thing as fixed length lists in PEP 484. You should use tuples instead.

I propose to just close this as wontfix, since the proposed additional overload will produce too many false negatives, plus inferred types will be often weird, e.g. dict([[1, "hi"]]) will be Dict[object, object], which will produce even more false positives down the road.

[adamtheturtle]

@ilevkivskyi - I appreciate that this case is perhaps too annoying to make work.

For more context, some code which is closer to the original that I am trying to type hint:

from typing import Dict

my_strings = ['foo=bar', 'baz=bat', 'apple=pair=orange']
my_dict: Dict[str, str] = dict(my_string.split('=', 1) for my_string in my_strings)
print(my_dict)  # {'foo': 'bar', 'baz': 'bat', 'apple': 'pair=orange'}

What this will likely change to is:

from typing import Dict

my_strings = ['foo=bar', 'baz=bat', 'apple=pair=orange']
my_dict: Dict[str, str] = dict((my_string.split('=', 1)[0], my_string.split('=', 1)[1]) for my_string in my_strings)
print(my_dict)  # {'foo': 'bar', 'baz': 'bat', 'apple': 'pair=orange'}

This is in a legacy codebase, where convincing folks to add type hints is already a challenge, never mind convincing them that it needs code changes in the logic itself!

[srittau]

Personally, I prefer false negatives over false positives, but I think @ilevkivskyi's argument about weird inferred types is pretty compelling. Actually, this already came up in #2287 and there is an open typing issue: python/typing#592. I am inclined to close this here for now.

Maybe we should create a label for things we can't fix in the current type system, so we can revisit those things later?

[ilevkivskyi]

OK, let's then close this as a duplicate of python/typing#592.

[ilevkivskyi]

Maybe we should create a label for things we can't fix in the current type system, so we can revisit those things later?

This is a good idea assuming someone volunteers to find and label such closed issues :-)