Haskell does something similar to this..
ls :: [String]
ls = [“hello”, “world”]
t :: (String, Int)
t = (“hello”, 5)
While at it, why don’t we pattern match function parameters like Haskel. Very
elegant way for function overload.
Something like this …
case def func(int(x), [float(y), *_], int(z)) if z != 0 -> int:
return int((x + y) / z)
case def func(int(x), [float(y), *_], int(z)): -> int:
return 0
case def func(_):
raise
# func(1, [1.2, 3, 5], 3) -> (1 + 1.2) / 3
# func(1, [1.2], 0) -> 0
# func("dummy", [1.2, 3, 5]) -> raise error
No need to precede it with the “match” statement because we are pattern
matching function parameters here in those cases. Also, annotating the
parameters will be redundant.
Abdulla
> On 28 Jul 2021, at 3:42 AM, Ignacio Pickering <[email protected]> wrote:
>
> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/SUYRV7DTKSNNFLXLR74GWNQ632WTBCDL/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/ROYZNX4U5VMWZMJJ7AZY6KUGGJ2HYKGX/
Code of Conduct: http://python.org/psf/codeofconduct/
