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.

Inizia da stdlib/builtins.pyi, in corrispondenza degli overload collegati del costruttore dict(), e confrontali con le chiamate di esempio nell’issue. Verifica come i type checker pertinenti gestiscono questi casi, quindi determina se la policy prevista consiste nell’accettare input più ampi validi a runtime; per completare il lavoro sono necessari un design degli overload concordato e la relativa validazione.