On Tue, Apr 13, 2021 at 6:48 PM Larry Hastings <larry@hastings.org> wrote:

On 4/13/21 1:52 PM, Guido van Rossum wrote:
On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings <larry@hastings.org> wrote:

On 4/12/21 7:24 PM, Guido van Rossum wrote:
I've been thinking about this a bit, and I think that the way forward is for Python to ignore the text of annotations ("relaxed annotation syntax"), not to try and make it available as an expression.

To be honest, the most pressing issue with annotations is the clumsy way that type variables have to be introduced. The current convention, `T = TypeVar('T')`, is both verbose (why do I have to repeat the name?) and widely misunderstood (many help request for mypy and pyright follow from users making a mistaken association between two type variables that are unrelated but share the same TypeVar definition). And relaxed annotation syntax alone doesn't solve this.

Nevertheless I think that it's time to accept that annotations are for types -- the intention of PEP 3107 was to experiment with different syntax and semantics for types, and that experiment has resulted in the successful adoption of a specific syntax for types that is wildly successful.


I don't follow your reasoning.  I'm glad that type hints have found success, but I don't see why that implies "and therefore we should restrict the use of annotations solely for type hints".  Annotations are a useful, general-purpose feature of Python, with legitimate uses besides type hints.  Why would it make Python better to restrict their use now?


Because typing is, to many folks, a Really Important Concept, and it's confusing to use the same syntax ("x: blah blah") for different purposes, in a way that makes it hard to tell whether a particular "blah blah" is meant as a type or as something else -- because you have to know what's introspecting the annotations before you can tell. And that introspection could be signalled by a magical decorator, but it could also be implicit: maybe you have a driver that calls a function based on a CLI entry point name, and introspects that function even if it's not decorated.


I'm not sure I understand your point.  Are you saying that we need to take away the general-purpose functionality of annotations, that's been in the language since 3.0, and restrict annotations to just type hints... because otherwise an annotation might not be used for a type hint, and then the programmer would have to figure out what it means?  We need to take away the functionality from all other use cases in order to lend clarity to one use case?


Yes, that's how I see it.

And before you get too dramatic about it, the stringification of annotations has been in the making a long time, with the community's and the SC's support. You came up with a last-minute attempt to change it, using the PEP process to propose to *revert* the decision already codified in PEP 563 and implemented in the master branch. But you've waited until the last minute (feature freeze is in three weeks) and IMO you're making things awkward for the SC (who can and will speak for themselves).
 

Also, if you're stating that programmers get confused reading source code because annotations get used for different things at different places--surely that confirms that annotations are useful for more than just type hints, in real-world code, today.


No, it doesn't, it's just a hypothetical that they *would* be confused if there *were* other uses. Personally I haven't used any libraries that use non-type-hint annotations, but I've been told they exist.

I genuinely have no sense of how important static type analysis is in Python--personally I have no need for it--but I find it hard to believe that type hints are so overwhelmingly important that they should become the sole use case for annotations, and we need to take away this long-standing functionality, that you suggest is being successfully used side-by-side with type hints today, merely to make type hints clearer.


For projects and teams that use type hints, they are *very* important. For example, they are so important to the Instagram team at Facebook that they wrote their own static type checker when they found mypy wasn't fast enough for their million-line codebase. And of course they were so important to Dropbox that they sponsored a multi-year, multi-person effort to create mypy in the first place. The amount of feedback we've received for mypy indicates that it's not just those two companies that are using type hints.

--
--Guido van Rossum (python.org/~guido)