Currently type hints for built-in containers are, in my opinion, less succint than required. I suspect it is probably not very difficult for a type checker to interpret something like this for example:

var1: {str: (int, int)} = {"label": (1, 2)}
var2: {str} = {"other_label"}

def function(param1: {int: str} = {1: "foo"}, param2: (int, ...) = (1, 2, 3)) -> (int, (str, ...)):
    return 3, ("foo", "bar")

as equivalent to:

var1: dict[str, tuple[int, int]] = {"label": (1, 2)}
var2: set[str] = {"other_label"}

def function(param1: dict[int, str] = (1, "foo"), param2: tuple[int, ...] = (1, 2, 3)) -> tuple[int, tuple[str, ...]]:
    return 3, ("foo", "bar")

I thought of posting something like this as a mypy feature suggestion, but I suspect the language would need to modify the way type annotations are interpreted for something like it to work (or maybe not?).
Basically, inside a type annotation, the objects created by (a, b), [a], {a: b}, {a} would be reinterpreted as the same thing as constructing tuple[a, b], dict[a, b], list[a], set[a].
I have found myself wanting to write things like this a couple of times, so I think this overloaded usage of builtin containters is natural.
I actually feel it is so natural it must either have been proposed before (in which case I would love to give the feature my +1) or there is some more or less obvious flaw.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SUYRV7DTKSNNFLXLR74GWNQ632WTBCDL/
Code of Conduct: http://python.org/psf/codeofconduct/