On Sun, Jan 9, 2022 at 3:47 PM Steven D'Aprano <steve@pearwood.info> wrote:
The point I am making here is not that I was a dimwit who couldn't even read Python, but that "easy to read" and "readable" is more a matter of familiarity than an inherent property of the language itself. With enough familiarity, even APL is easy to read.
Can attest. Not specifically about APL, but there are times when I've watched an expert casually reading off a series of electrical meters or other indicators and immediately knowing what something means. For myself, I've read hex dumps as easily as software code, because specific constructs are incredibly obvious (a series of 32-bit Hollerith strings, for instance, is quite easy to read if you know what you're looking at). The most important feature of Python's type hints, like most other constructs, is knowing where one begins and ends. If you're eyeballing a massive blob of code and you find an open quote character, it should be straight-forward to figure out the extent of the string literal. If you're browsing a function and come across a 'while' loop, you should be able to find the end of that loop. And if you're reading a function's parameters, you should be able to understand how much of it is the annotation and where the next parameter begins. To that extent, I definitely want to keep annotation syntax and Python syntax the same; if there's a new feature needed for annotations, add it to the base language, even without any useful semantics. (Valid syntax without semantics is what we have with the matmul operator. I can syntactically parse "f@g(y)" because I know how the matmul operator works, even without knowing the data types involved. If "x->y" is syntactically valid anywhere in Python code, it's not a problem that there are no core data types for which it's meaningful.) ChrisA