Dear Typing Community!
I just wanted to share with you an idea about syntax regarding type aliases, alternative to the one currently in PEP 695.
PEP says
> We propose to introduce a new statement for declaring type aliases. Similar to class and def statements, a type statement defines a scope for type parameters.
But the proposed syntax looks rather like C code (`int x = 5`) and feels a bit strange in python:
It reminds me more of Haskell than C. C type aliases look like `typedef int str;`.
```python
# A non-generic type alias
type IntOrStr = int | str
# A generic type alias
type ListOrSet[T] = list[T] | set[T]
```
So my humble proposition is to introduce a truly pythonic syntax:
```python
# A non-generic type alias
type IntOrStr:
int
str
Doesn't seem that Pythonic to me. In every other block (except match), the lines inside the block are statements, not types.
# A generic type alias
type ListOrSet[T]:
list[T]
set[T]
```
While it takes more lines, it has the following advantages:
1. More pythonic
No new C-flavoured syntax like `key_word name = value`, but a well known style like with class, def, with, match, case etc.
2. No need to use `\`
Type names happen to be very long in real life projects. Pythonic syntax allows to avoid line continuation characters.
3. No need for `|`
While it is elegant and cute, the new line can take its role gracefully.
Not all type aliases are unions. It's odd to me to privilege unions in this way.
4.More readable diffs when someone adds or removes types.
For example when we allow the `ListOrSet` to be None
```python
type ListOrSet[T]:
list[T]
set[T]
None
```
The diff will show accurately what was added, without a need to check which parts of the long line were modified. Readability counts. ;)
5. Clear scope of T.
It naturally plays with this requirement:
> Type parameters declared as part of a generic type alias are valid only when evaluating the right-hand side of the type alias.
6. In the spirit of making types first class citizens open for future extensions.
While this last argument may be a bit vague, it feels that my pythonic type alias syntax will leave more room for next possible syntax enhancements if in a few years from now we discover such a need.
In case you have already discussed such a pythonic syntax but for some reason rejected it, it may be worth adding it to the Rejected Ideas section.
It's my first time on the python mailing list, so if you find my proposition somehow inappropriate or flawed, please accept my apologies for wasting your time.
Have a great Halloween weekend!
- Maciej
_______________________________________________
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: jelle.zijlstra@gmail.com