[pyflakes] Avoid false positives in @no_type_check contexts (F821, F722)
#14615
Conversation
This reverts commit 9aa4913.
| if decorator | ||
| .expression | ||
| .as_name_expr() | ||
| .is_some_and(|name| name.id.as_str() == "no_type_check") |
There was a problem hiding this comment.
I think this should use match_typing_expr so that it works for @typing.no_type_check too.
There was a problem hiding this comment.
So, will this apply to type annotations in the body of the function? And should it, per the spec? (I don't know off-hand.)
There was a problem hiding this comment.
Ah thanks, I missed match_typing_expr.
Yes, this should apply to annotations in the body too, based on my reading of the no_type_check docs:
This works as a class or function decorator. With a class, it applies recursively to all methods and classes defined in that class (but not to methods defined in its superclasses or subclasses). Type checkers will ignore all annotations in a function or class with this decorator.
Similarly in the typing docs linked in what Micha linked:
If a type checker supports the no_type_check decorator for functions, it should suppress all type errors for the def statement and its body including any nested functions or classes. It should also ignore all parameter and return type annotations and treat the function as if it were unannotated.
I added annotated variables to the test fixtures in my last commit to check this.
|
There was a problem hiding this comment.
I looked into the @no_type_check for red knot and I think we should ignore it for classes, the same as pyright. See https://discuss.python.org/t/no-type-check-decorator/43119.
Edit: The relevant typing spec change https://github.com/python/typing/pull/1615/files
|
Ah okay, happy to revert the class part. That's what I had initially anyway since that's all that was reported in #13824. |
|
Thanks |
Summary
These changes avoid the false positives reported in #13824, where both F821 (undefined name) and F722 (syntax error in forward annotation) were triggered in function signatures decorated with typing.no_type_check. In line with the discussion on the issue, the code now skips visiting type definitions when in a context where this decorator was found. While the initial report only covered the function decorator, the docs indicate that classes can also be decorated, so this context is also checked when visiting class definitions, and the new tests reflect that.
Test Plan
These changes were tested by including the code snippets triggering the issue as new snapshot tests. As mentioned above, these snapshots are also augmented with
classvariants. I also added invalid annotations to the function and method bodies to make sure theno_type_checkcontext applied to the bodies too.