Detecting Any in generic types and variables
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 49.7k
- Forks
- 2.4k
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 458
Description
This is a continuation from issue #5803, which assumed the lack of support for this is a bug, which it was not, making it a feature request.
The proposal here is that currently, the flake8-annotations rules only detect the Any type when used in function arguments, or their return types directly. I think it would be beneficial to also add new linter rules (or extend the existing ANN401, however that would make it different from the original handling in flake8-annotations).
Here's a recap of the issue:
Any in generic arguments
from typing import Any
def foo(x: dict[str, Any]) -> None: # Should be an error
...
def bar() -> list[Any]: # Should be an error
...
I think there is value in having a linter rule capable of finding use of Any in these kinds of nested type definitions too. Even though they are a much more precise than just pure Any, there is still a lot of ambiguity being introduced there, and there's no good reason for it.
If a function can really accept any kind of values, it should use object in the annotation, not Any. As an example: Mapping[str, object] would be a much better option than Mapping[str, Any], because the type checker would later not allow you to blindly access any variable or name from that any type, while still allowing any kinds of objects in.
Any in variable annotations
from typing import Any, ClassVar
x: Any = 5 # Should be an error
class Foo:
X: ClassVar[Any] = 10 # Should be an error
Y: Any = 50 # Should be an error
There is no reason to only disallow the use of Any in functions, but not in variables. It brings in just as much type ambiguity as in functions.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing issue #5803 and the existing ANN401 handling. Define and implement the agreed coverage for Any nested in generic annotations and in variable annotations, then verify that the examples in this issue are reported as errors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, rust
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100