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 <gu...@python.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 > <alkathiri.abdu...@gmail.com <mailto:alkathiri.abdu...@gmail.com>> 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 > > return wrapper > > > 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 > > return wrapper > > 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 -- python-ideas@python.org > <mailto:python-ideas@python.org> > To unsubscribe send an email to python-ideas-le...@python.org > <mailto:python-ideas-le...@python.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://mail.python.org/archives/list/python-ideas@python.org/message/LRUXIJXCY5J274MWWNKLARB3R6UOPCUM/ > > <https://mail.python.org/archives/list/python-ideas@python.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/>
_______________________________________________ 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/ZXITNUQYDB23CRTSORODEWQS6Y6Q5DAP/ Code of Conduct: http://python.org/psf/codeofconduct/
