
Hi, tl;dr: imho the like or dislike of PEP 563 is related to whether people intend to learn a second syntax for typing, or would rather ignore it; both groups should be taken into account. Le 13/04/2021 à 19:30, Guido van Rossum a écrit :
On Tue, Apr 13, 2021 at 9:39 AM Baptiste Carvello <devel2021@baptiste-carvello.net <mailto:devel2021@baptiste-carvello.net>> wrote:
Then, what's wrong with quoting? It's just 2 characters, and prevent the user (or their IDE) from trying to parse them as Python syntax.
Informal user research has shown high resistance to quoting.
OK, but why? I'd bet it's due to an "aesthetic" concern: for typing users, type hints are code, not textual data. So it irks them to see them quoted and syntax-highlighted as text strings.
As a comparison: docstrings do get quoting, even though they also have special semantics in the language.
Not the same thing. Docstrings use English, which has no formal (enough) syntax. The idea for annotations is that they *do* have a formal syntax, it just evolves separately from that of Python itself.
If I may say it in my words: to both the parser and (more importantly) typing-savvy developers, type hints are code. I now see the point. But what about developers who won't learn this (future) incompatible typing syntax, and only encounter it in the wild? To them, those annotations are akin to docstrings: pieces of textual data that Python manages specially because of their role in the greater ecosystem, but that they can ignore because the program behavior is not modified. So it will irk them if annotations in this new syntax are not quoted or otherwise made distinguishable from code written in the normal Python syntax they understand. Again the "aesthetic" concern, and imho it explains in large part why some people dislike PEP 563. Can the needs of both groups of developers be addressed? Could code in the new typing syntax be marked with a specific syntactic marker, distinguishing it from both normal Python syntax and text strings? Then this new marker could also be used outside of annotations, to mark analysis-time-only imports or statements? Or is this all not worth the expense, and typing syntax can manage to stay compatible with normal Python syntax, in which case PEP 649 is the way to go? Cheers, Baptiste