With `--disallow-any-decorated`, `Any` detection logic changes w/wo decorator

[243f6a8885a308d313198a2e037]

Bug Report

(A clear and concise description of what the bug is.)

We expect that adding a decorator to a method will never produce a new mypy error unless the decorator itself introduces a new Any annotation, i.e. expect no new error if the decorator itself does not introduce any additional Any.

We also believe that it is difficult to call this behavior a bug. The behavior of the option itself seems self-evident in its own way.

But we would expect a situation where simply applying a harmless decorator would not change the presence or absence of errors.

To Reproduce

Here is a test case.

[case testDisallowAnyDecoratedShouldNeverAffect]
# flags: --disallow-any-decorated

import dataclasses
from typing import Any, Callable

from typing_extensions import TypedDict, TypeVar

class CtxAny(TypedDict):
    place: Any

CallableT = TypeVar("CallableT")

def custom_decorator(func: CallableT) -> CallableT:
    return func

class Something:
    # No error
    def do(self, ctx: CtxAny) -> None:
        pass

    @classmethod
    # This emits an error, unexpected.
    def do_classmethod(cls, ctx: CtxAny) -> None:  # E: Type of decorated function contains type "Any" ("Callable[[Type[Something], CtxAny], None]")
        pass

    @custom_decorator
    # This emits an error, unexpected.
    def do_custom_decorator(self, ctx: CtxAny) -> None:  # E: Type of decorated function contains type "Any" ("Callable[[Something, CtxAny], None]")
        pass
[builtins fixtures/classmethod.pyi]

Expected Behavior

We expect do and others to be the same error-condition.

i.e. one of:

• No mypy errors emitted.
• All (containing do method) emits an error.
  • If some option allows us to emit an error on do method, it will be fine.

Actual Behavior

As shown in reproduction code.

Your Environment

• Mypy version used:current master
• Mypy command-line flags:--disallow-any-decorated
• Mypy configuration options from mypy.ini (and other config files):
• Python version used: 3.8.16, 3.11.3

[243f6a8885a308d313198a2e037]

Maybe using --disallow-any-expr --disallow-any-explicit without --disallow-any-decorated is one answer?

→ These options are too strict for real application ... 😢

[Dreamsorcerer]

This does seem kind of annoying when using this option. You'd expect an option about decorators to only trigger errors caused by decorators. An error because a function has an explicit Any in the function itself is already covered by the stricter flags (disallow-any-explicit or disallow-any-expr).

If the behaviour of this flag were changed as described above, it would provide a good way to ensure that typing information isn't lost in large quantities (due to a decorator used throughout the codebase). But, currently it just causes too many false positives due to it overlapping the behaviour of other flags.

[Dreamsorcerer]

Not sure exactly what's changed in 1.16, but these errors are a lot less frequent.
In the reproducer above, the first error no longer occurs, though the second one still does.

I see classmethod is defined as a class, so maybe if the decorator returns a class, it no longer triggers the error? But, a simple decorator function does?