Should dict() constructor overloads be more permissive?

Current constructor overloads are here:

https://github.com/python/typeshed/blob/e80ad6b2bce7ef6b2a20aec2d79a672859b31864/stdlib/builtins.pyi#L1041-L1046

Someone took care to allow specific positive case, and to block specific negative case.
Many potential valid uses have fallen through the cracks:

dict([[1, 2]])
dict("AT TA GC CG".split())
dict([["str", b"bytes"]])

My understanding of the issue is that there's no way to specify sequence length (other than a tuple) in a type hint, that is there's no syntax to hint ["a", "b"] vs ["a", "b", "c"].

This brings a philosophical question: what side should typeshed err on when type hint syntax is not precise enough?

• type whatever Python may accept run time, or
• restrict users to what Python is guaranteed to accept at run time?

It was mentioned at https://github.com/microsoft/pyright/issues/7382 that type checkers trust typeshed, and thus the question belongs here.

My personal preference would be for permissive type hints in these cases.

Start with stdlib/builtins.pyi at the linked dict() constructor overloads and compare them with the example calls in the issue. Check how the relevant type checkers handle those cases, then determine whether the intended policy is to accept broader runtime-valid inputs; done requires an agreed overload design and corresponding validation.