astral-sh / astral-sh/ruff

Detecting Any in generic types and variables

Open
#5,871 4 comments 7 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

rule typing
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.