-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make support for type comments optional #1533
Comments
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 |
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 I don't see a remaining use case for type comments, except backwards compatibility. |
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 |
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.
The text was updated successfully, but these errors were encountered: