Typescript-Like Notational Shortcuts
On the theme of the addition of pip operators to indicate union, I was wondering what people think of using the following shortcuts for type hints. * type[] be a short-hand for List[type] * [type1, type2, type3] be a shorthand for Tuple[type1, type2, type3] * similar ideas for dictionaries and callables with (perhaps with javascript-like arrow notations?) I just think something like this would be easier to read. For example, a lot of functions that return tuples generally are immediately unpacked when it's used, so I think this is a more clear and concise way of stating that this is that it returns three elements: an element of type1, an element of type2 and an element of type3. In other words, the fact that it's a tuple does not matter much.
On Tue, 2022-05-31 at 21:08 +0000, kevinlu1248@gmail.com wrote:
On the theme of the addition of pip operators to indicate union, I was wondering what people think of using the following shortcuts for type hints.
* type[] be a short-hand for List[type] I'm at -½ on this idea. Using list[type] isn't really problematic for me today.
* [type1, type2, type3] be a shorthand for Tuple[type1, type2, type3] I think this would problematic because today it already validly expresses a list containing the elements: type1, type2 and type3. And all it saves is 5 characters: `tuple`.
* similar ideas for dictionaries and callables with (perhaps with javascript-like arrow notations?)
I'm +1 for the idea of a more intuitive callable type hint syntax.
I just think something like this would be easier to read. For example, a lot of functions that return tuples generally are immediately unpacked when it's used, so I think this is a more clear and concise way of stating that this is that it returns three elements: an element of type1, an element of type2 and an element of type3. In other words, the fact that it's a tuple does not matter much.
I talked about this before but I have slightly different suggestions list[type] becomes [type] tuple[type1, type2, type3] becomes (type1, type2, type3) dict[type1, type2] becomes {type1: type2} set[type] becomes {type} Callable[[type1], type2] becomes (type1) -> type2 class MyTypedDict(TypedDict): name: str age: NotRequired[int] becomes {name: str, age: NotRequired[int]} Unfortunately, the steering committee rejected the callable syntax last year even though I think the proposal was elegant and a lot of efforts went into it. Maybe they will reconsider it in the future with some modifications? I don’t know. Abdulla Sent from my iPhone
On 1 Jul 2022, at 7:17 AM, Paul Bryan <pbryan@anode.ca> wrote:
On Tue, 2022-05-31 at 21:08 +0000, kevinlu1248@gmail.com wrote:
On the theme of the addition of pip operators to indicate union, I was wondering what people think of using the following shortcuts for type hints.
* type[] be a short-hand for List[type] I'm at -½ on this idea. Using list[type] isn't really problematic for me today.
* [type1, type2, type3] be a shorthand for Tuple[type1, type2, type3] I think this would problematic because today it already validly expresses a list containing the elements: type1, type2 and type3. And all it saves is 5 characters: `tuple`.
* similar ideas for dictionaries and callables with (perhaps with javascript-like arrow notations?)
I'm +1 for the idea of a more intuitive callable type hint syntax.
I just think something like this would be easier to read. For example, a lot of functions that return tuples generally are immediately unpacked when it's used, so I think this is a more clear and concise way of stating that this is that it returns three elements: an element of type1, an element of type2 and an element of type3. In other words, the fact that it's a tuple does not matter much.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/NTAPUM... Code of Conduct: http://python.org/psf/codeofconduct/
participants (3)
-
Abdulla Al Kathiri -
kevinlu1248＠gmail.com -
Paul Bryan