Function having return type as type variable with `Callable` bound does not allow `Callable[..., Any]` to be returned

[Glinte]

Discussion: #10700

The type (...) -> Any is the gradual form of a callable. It's the equivalent of Any, and it should be assignable to any callable (and vice versa), so wrapped should be assignable to the return type.

Playground

from typing import Any, Callable, TypeVar

Fn = TypeVar("Fn", bound=Callable)

any_fn: Callable = lambda: None
def decorator(fn: Fn) -> Fn:
    return any_fn
#          ^^^^^^
# Type "(...) -> Unknown" is not assignable to return type "Fn@decorator"
#   Type "(...) -> Unknown" is not assignable to type "Fn@decorator"  (reportReturnType)

[Azureblade3808]

Callable[..., Any] is compatible with Callable with any possible signature.

Callable[..., Any] is NOT compatible with all subtypes of Callable.

According to your snippet, one will expect that the result of decorator(int) to be int(as int is callable), but get any_fn in surprise.

[Glinte]

Two things
1.

Callable[..., Any] is NOT compatible with all subtypes of Callable.

Sounds right, maybe eric made a mistake in the discussion?

The issue being that you can make a subclass of Callable

class MyCallable:
    x: int
    __call__: ...

fn = MyCallable()
new_fn = decorator(fn)
^^^^^^
# Should be MyCallable by type annotations, but actually decorator returns Callable

According to your snippet, one will expect that the result of decorator(int) to be int(as int is callable), but get any_fn in surprise.

That is just because I intentionally erased the type information via any_fn: Callable to demonstrate the issue. If (incorrectly) Callable[..., Any] is compatible with all subtypes of Callable then it is the same situation as the following, so your example doesn't demonstrate the issue your're talking about

x: Any = 1
def f(_: str) -> str:
    return x

[erictraut]

@Azureblade3808, what do you mean by "compatible with"? We intentionally avoid that term in the typing spec because it's somewhat ambiguous. Instead, we use the terms assignable to and consistent with. Both of them have unambiguous definitions. Consistency implies bidirectional assignability.

According to the typing spec, a Callable that uses ... is consistent with any input signature. See here.

[Azureblade3808]

@Azureblade3808, what do you mean by "compatible with"? We intentionally avoid that term in the typing spec because it's somewhat ambiguous. Instead, we use the terms assignable to and consistent with. Both of them have unambiguous definitions. Consistency implies bidirectional assignability.

According to the typing spec, a Callable that uses ... is consistent with any input signature. See here.

Yeah, I meant consistent.

[Azureblade3808]

That is just because I intentionally erased the type information via any_fn: Callable to demonstrate the issue. If (incorrectly) Callable[..., Any] is compatible with all subtypes of Callable then it is the same situation as the following, so your example doesn't demonstrate the issue your're talking about

You got me.

According to your snippet, one will expect that the result of decorator(int) to be int(as int is callable), but get any_fn in surprise.

Reworded:

According to your snippet, one will expect that the result of decorator(int) to be int(as int is callable) and the result type is type[int], but Callable(the type of any_fn) is not assignable to type[int].

[Glinte]

Yeah, seems like a non-bug to me now, but I will leave it for Eric to decide. Also, now I am officially unsure how to preserve the docstring of an overloaded function #10700