Initially, when I wrote this, I had a similar syntax to what you wrote. I like it, I changed it to brackets so we could contain Callable that has multiple arguments or return value as Callables themselves.
E.g., function that has two Callables as arguments and a Callable return looks like this..
f: ((int, str) -> int, (…) -> str) -> (str) -> int
The arguments are clear to me but the callable return confuses me a little (the last two ->’s). However, the return value does’t have parenthesis, I still could see the consistency (arguments) -> return. But my mind is focusing on the last item, int, instead of the whole (str) -> int for some reason.
[[int, str -> int], [… -> str] -> [str -> int]] looks uglier but the one before last “->" clearly communicates that the return value is callable.
Regardless of how it’s done, the less we depend on the typing module for annotations, the better I think because it encourages python users to annotate their functions.
On Nov 28, 2020, at 9:31 PM, Guido van Rossum firstname.lastname@example.org wrote:
I'm not so keen on the square brackets you propose. How about we write Callable[[x, y], z] as (x, y) -> z instead? Callable[, z] would become () -> z, and Callable[..., z] could become (...) -> z, the latter being a bit of an anomaly, but manageable, and better than (*_, **_) -> z which looks like some kind of weird emoji. :-)
On Sat, Nov 28, 2020 at 8:50 AM Abdulla Al Kathiri <email@example.com mailto:firstname.lastname@example.org> wrote:
I don’t know if this has been discussed before.
Similar to PEP 645 idea of writing "Optional[type]" as “type?”, I propose we write "Callable[[type1, type2, ...], type3]” as “[type1, type2, … -> type3]”. Look at the two examples below and see which one looks better to the eyes:
def func1(f: typing.Callable[[str, int], str], arg1: str, arg2: int) -> str: return f(arg1, arg2)
def func2(f: [str, int-> str], arg1: str, arg2: int) -> str: return f(arg1, arg2)
There is less clutter especially if we have nested Callables.
e.g., f: Callable[[str, int], Callable[[int,…], str]] becomes f: [str, int -> [int, ... -> str]]
Callable without zero arguments.. f: Callable[, str] would become f: [ -> str]
Equivalent to Callable alone without caring about arguments and the return value would be [… -> typing.Any] or [… -> ]
Let’s say we have a function that accepts a decorator as an argument. This might not be useful to do, but I want to show case how it would be easier to read. The old way would be:
def decorator(f: Callable[…, int]) -> Callable[…, tuple[int, str]]:
def wrapper(*args, **kwargs) -> tuple[int, str]: text = “some text” res = f(*args, **kwargs) return res, text
def function(decorator: Callable[[Callable[…, int]], Callable[…, tuple[int, str]]], decorated_on: Callable[…, int]) -> Callable[…, tuple[int, str]]: wrapper = decorator(decorated_on) return wrapper
The new way is as follows:
def decorator(f: [… -> int]) -> [… -> tuple[int, str]]:
def wrapper(*args, **kwargs) -> tuple[int, str]: text = “some text” res = f(*args, **kwargs) return rest, text
def function(decorator: [ [… -> int] -> [… -> tuple[int, str]]], decorated_on: [… -> int]) -> [… -> tuple[int, str]]: wrapper = decorator(decorated_on) return wrapper
I saw something similar in Pylance type checker (VSC extension) when you hover over an annotated function that has Callable as an argument or a return value, but they don’t seem to use brackets to mark the beginning and end of the callable, which could be hard to follow mentally (see screenshot below)
<Screen Shot 2020-11-28 at 8.30.09 PM.png>
Personally, I think it would be easier if Pylance wrote the hint like the following:
(function) function: (decorator: [p0:[*args: Any, **kwargs: Any -> int ]] -> [*args: Any, **kwargs: Any -> tuple[int, str]], decorated_on: [*args: Any, **kwargs: Any -> int]) -> [*args: Any, **kwargs: Any -> tuple[int, str]]
Python-ideas mailing list -- email@example.com mailto:firstname.lastname@example.org To unsubscribe send an email to email@example.com mailto:firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/LRUXIJ... https://firstname.lastname@example.org/message/LRUXIJXCY5J274MWWNKLARB3R6UOPCUM/ Code of Conduct: http://python.org/psf/codeofconduct/ http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido http://python.org/~guido) Pronouns: he/him (why is my pronoun here?) http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/