PEP 677: Include more rejected alternatives #2219
Conversation
- Rust-style syntax - Forced outer parentheses - Improving readability of existing callable type
pep-0677.rst
Outdated
| - We agree that it might make sense to encourage outer parentheses in several | ||
| cases, particularly callable types in function return annotations. But we | ||
| believe it is more appropriate to encourage this in style guides, linters, | ||
| and autoformatters than to bake it into the parser and throw syntax errors. |
There was a problem hiding this comment.
Also, this entire example looks unPythonic, and even if such a function would make sense, I'd probably use a type alias to make the return type less look like line noise.
There was a problem hiding this comment.
Simplified the example a bit and added a bullet about type aliasing as a solution.
Although I have some skepticism about type aliases as a general answer to complex types. Based on the production typed-python code I see I, developers seem hesitant to use them (at least at Meta).
I can understand why. Most code forms a graph where you constantly have to jump-to-source to understand it. One nice thing about types is that they normally speak for themselves. Once we use type aliases, that becomes less true - readers might have to jump hundreds of lines to the top of a module to see what a type actually represents.
This isn't necessarily a bad thing since type aliases provide abstraction and one kind of readability, but there is definitely a cost and it seems to me that many developers don't want to pay it.
There was a problem hiding this comment.
Yeah, it depends on lots of things. But I don’t want to feel that we have to do something just because Facebook coders prefer it. There’s a whole community here, and some people are already concerned that Python is more and more being controlled by enterprise developers.
Adding more options that came up in typing-sig and python-dev discussion.