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.
No, what I heard is that, since in *most* cases the string quotes are not needed, people are surprised and annoyed when they encounter cases where they are needed. And if you have a large code base it takes an expensive run of the static type checker to find out that you've forgotten the quotes.
> 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.
They will treat it as anything else they don't quite understand -- they will ignore it unless it bites them. And the rule for finding the end of an annotation would be very simple -- just skip words until the next comma, close paren or colon, skipping matching brackets etc.
Certainly I use this strategy all the time for quickly skimming code (in any language) that I don't need to completely understand -- "oh, this is where the parameters are processed, this is where the defaults are sorted out, and this is where the work is being done; and since I'm investigating why the default is weird, let me look at that part of the code in more detail."
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?
There already is a special marker for annotations in function definitions -- for arguments, it's the colon following the parameter name, and for return types, it's the arrow after the parameter list. And for variable declarations ("x: int") the same colon also suffices.
The idea to use the same marker for other analysis-time code is interesting, but the syntactic requirements are somewhat different -- annotations live at the "expression" level (informally speaking) and are already in a clearly indicated syntactic position -- analysis-time code looks just like other code and can occur in any position where statements can appear. So an appropriate marker would probably be an if-statement with a special condition, like "if TYPE_CHECKING" (I am all for making that a built-in constant, BTW).
If you were thinking of backticks, sorry, I'm not biting. (There are folks who have other plans for those -- presumably because it's one of the few ASCII characters that currently has no meaning.)
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?
I don't see much expense in the proposal to relax the syntax, and I see benefits for new kinds of type annotations (e.g. PEP 647 would have benefited).
And certainly PEP 649 has considerable cost as well -- besides the cost of closing the door to relaxed annotation syntax, there's the engineering work of undoing the work that was done to make `from __future__ import annotations` the default (doing this was a significant effort spread over many commits, and undoing will be just as hard). And we would still have to support stringification when that import is explicitly given for several more releases.