-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[feature-request] Detect invalid unquoted imports #5753
Comments
We can definitely detect that, we already capture this in our semantic model. Meanwhile this, I believe, is fine: from typing import TYPE_CHECKING
if TYPE_CHECKING:
from threading import Thread
def foo():
t: Thread = 1
return t
foo() |
Great! Yes, ^^ is fine because Python never evaluates local variable annotations-- the annotation for a local variable is always a string, regardless of |
Btw IMO there should be autofix that converts it to a quoted string-- so my request here is similar to #5559. |
Unfortunately I've become intimately familiar with all the rules around annotation semantics 😂 |
Do you think this should just be caught by F821, with a custom suggestion and autofix to quote it? Or a separate rule? |
Certainly sense to me to catch under an existing undefined anme rule, but I guess ultimately it depends on how much you are trying to mirror exact behavior of the rules you ported from other linters. |
May be easier to just implement this as the TC200 rules from flake8-type-checking. |
This is a bit different than the request in #5559, which is to automatically quote any annotations that can be quoted (and are only used in typing contexts), right? |
Yeah it's definitely different, they just both involve adding quotes to annotations. |
The following code crashes at runtime:
The issue is that
Thread
is not defined at runtime, since it's only imported in aTYPE_CHECKING
block. Butruff
does not detect any error.If this module included
from __future__ import annotations
, then it would be OK because "Thread" would be interpreted as a string-- but the module doesn't include that, so it should be possible to detect that this is illegal.Further, I think in Python 3.13 string annotations, derived from
from __future__ import annotations
or otherwise, will go away in favor of wrapping annotations in a function for deferred evaluation. See here and PEP 649 for the dirty details.The text was updated successfully, but these errors were encountered: