Make support for type comments optional

[JelleZijlstra]

PEP 484 (and therefore the current typing spec) implies that type checkers must support the old "type comment" syntax. However, this syntax is unnecessary since Python 3.6 and PEP 526, so there is little reason for new type checkers to support it.

I think we should no longer make support for type comments mandatory. We can keep describing the intended semantics of type comments, but say that type checkers are free to drop support for them. Code that is intended to work across type checkers (e.g., library stubs) should not use them.

PEP 484 (and therefore this spec) imply that type checkers must support the old "type comment" syntax. However, this syntax is unnecessary since Python 3.6 and PEP 526, so there is little reason for new type checkers to support it.

I think we should no longer make support for type comments mandatory. We can keep describing the intended semantics of type comments, but say that type checkers are free to drop support for them. Code that is intended to work across type checkers (e.g., library stubs) should not use them.

(Note that this does not include # type: ignore comments. Those are still useful and should continue to work.)

This isn't urgent so I'll likely not pursue this very soon, but I'm filing this issue to keep track of the idea. I previously filed JelleZijlstra/typing-spec#1, where one person spoke up because they still like type comments, but I'm planning to archive that repo.

[mikeshardmind]

I think this should be timed to when match when annotations are automatically lazily evaluated and after the last version where types in the standard library were not properly generic at runtime. Keep in mind things like asyncio.Queue cannot be subscripted at runtime in python 3.8, and array.array is not subscriptable at runtime until 3.12. Doing this prior to when 3.11 is no longer supported would be a problem

[srittau]

I don't think this change should be dependent on lazy evaluation and generics in the stdlib. Lazy evaluation is already available in all supported Python versions through from __future__ import annotations and this also mostly fixes the missing generics problem. In cases where it doesn't, types can be quoted.

I don't see a remaining use case for type comments, except backwards compatibility.

[mikeshardmind]

It doesn't fix this, as this will cause errors when people use tools that are also in the standard library to inspect annotations. Some of this kind of inspection of types at runtime has become popular enough that it's pretty common to be done by libraries for various reasons. There's not a way to properly handle some things in the standard library until at least 3.12 by my reckoning, and that's just based on the things I'm aware of. A stringified annotation is still supposed to be valid when eval'd, and typing.Annotated exists for non-type information.