Re: Compact syntax for Callable: `(Arg1, Arg2) -> Ret`
I dislike the syntax of (str, int, int -> int). This can be read as (str, int, int) -> int or as tuple[str, int, int -> int]. The second is how some languages (haskell) would read it as. One question is it fine to nest callables and how does associativity/precedence work for this? int -> int -> bool fine? That's a fairly common pattern in function languages and it'd be nice to stay similar to them. I think of -> as binding weakly and that int -> int -> bool == int -> (int -> bool) (right associativity). Right associativity is needed if you want curry/uncurrying to not need a lot of parentheses. I weakly prefer -> over =>, but either is a great improvement over Callable[] stacks. Also while keyword/other callable details would be nice, I'd like some simple solution like this for the most common easy cases. Any solution that supports more complex callables I'd want to allow something as simple as int -> bool to not need more stuff.
I agree that mandatory parentheses around the argument types makes it more readable. This should also make it easier to extend the syntax in the future with optional named arguments, e.g. `(int, str, foo: bool) -> int`. This way you would be able to literally copy-paste a function def to use as type annotation or vice versa. On Thu, Jun 10, 2021 at 4:31 AM Mehdi Drissi via Typing-sig < typing-sig@python.org> wrote:
I dislike the syntax of (str, int, int -> int). This can be read as (str, int, int) -> int or as tuple[str, int, int -> int]. The second is how some languages (haskell) would read it as.
One question is it fine to nest callables and how does associativity/precedence work for this? int -> int -> bool fine? That's a fairly common pattern in function languages and it'd be nice to stay similar to them. I think of -> as binding weakly and that int -> int -> bool == int -> (int -> bool) (right associativity). Right associativity is needed if you want curry/uncurrying to not need a lot of parentheses.
I weakly prefer -> over =>, but either is a great improvement over Callable[] stacks. Also while keyword/other callable details would be nice, I'd like some simple solution like this for the most common easy cases. Any solution that supports more complex callables I'd want to allow something as simple as int -> bool to not need more stuff. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: dmrtzn@gmail.com
I don't much like allowing `(str, int, int -> int)` either, agree that it would seem ambiguous. I guess there's another open question of whether to require parentheses for one-argument functions, e.g. can you write `Callable[[int], int]` as `int -> int` like an ML-style language, or do we insist on `(int) -> int`. My preference would actually be to require the parentheses in order to preserve the "def-like" syntax, my guess is that `int -> int` would be a lot more likely to confuse newcomers. Bare `->` with right-associativity are a natural fit for languages with currying, but in python it seems less clear. If we require arguments in parentheses then questions about associativity and precedence mostly disappear: - `((int) -> bool) -> float` would be the only way to indicate a function that takes an `(int) -> bool` and returns a `float` - `(int) -> ((int) -> float)` would indicate a function taking an `int` and returning a `(bool) -> float` - if we decide not to mandate parentheses around return types, then we'd get a kind of right-associativity where this could also be written `(int) -> (bool) -> float`, which would be unambiguous
participants (3)
-
Daniel Mouritzen -
Mehdi Drissi -
Steven Troxler