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-le...@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/
