Incorrect Type Hint for `scan` Method in Redis Python Library

[nh916]

Description

The type hint for the scan method in the Redis Python library appears to be incorrect or overly broad. While the method is used in sync mode, the type hint suggests that it can return an Awaitable[Any] | Any, causing issues when using type-checking tools like mypy.

In practice, when using the sync mode, the scan method reliably returns a tuple[int, list[str]] as per the Redis documentation and behavior. However, the current type hint does not accurately reflect this.

Environment

• Redis Python Version: 5.2.0
• Python Version: 3.12.1
• Operating System: Mac

Steps to Reproduce

1. Use the scan method in sync mode with a Redis client.
2. Assign the result to a variable with the expected type tuple[int, list[str]].
3. Run mypy type-checking on the code.
4. Observe the mypy error.

Example Code

from redis import Redis

redis_client: Redis = Redis(host="localhost", port=6379, decode_responses=True)

# Expected type hint: tuple[int, list[str]]
scan_result: tuple[int, list[str]] = redis_client.scan(
    cursor=0, match="pattern:*", count=1000
)

Expected Behavior

When using the scan method in sync mode, the type should be annotated as:

tuple[int, list[str]]

This aligns with the Redis documentation and avoids unnecessary type-checking errors when using tools like mypy.

Current Behavior

The current type hint in the Redis Python library annotates the return value as:

Awaitable[Any] | Any

This causes mypy to raise errors when the scan method is used in a synchronous context. For example:

scan_result: tuple[int, list[str]] = redis_client.scan(cursor=0, match="pattern:*")

The above snippet results in the following error from mypy:

Incompatible types in assignment (expression has type "Awaitable[Any] | Any", variable has type "tuple[int, list[str]]")

[hglman]

Yes, this seems to be the case for most methods, its not clear how to tell mypy I'm using the Async version.

[vladvildanov]

Hey! Yeah, the issue is that we're using the same mixin with commands for both API's, that's why the signature contains a Union typing

[vladvildanov]

Unfortunately, the refactor is quite large and not in our list of priorities for now

[vladvildanov]

Would be resolved when we take care of refactoring RedisCommand trait