Incorrect type-var unification of generic function return type decorated with @lru_cache

[strangemonad]

Describe the bug
This is easiest illustrated with the repro-case below. In short, if you decorate an invariant generic method, the type-var unification doesn't seem to propagate across the LRU wrapped method. In the following code, the store_of method works fine but cached_store_of's type is still captured as the "T@cached_store_of" fresh Ty var instead of being unified with the Account type.

Note that in this case, the type var T must be invariant but that's incidental to this example. Custom decorators seem to work properly. I also believe I've confidently rule out that this is unrelated to TypeForm and any of the improvements that might bring to the table.

Code

import typing
from functools import lru_cache
from typing import Any, Generic, TypeVar

T = TypeVar("T")

class Store(Generic[T]):
    def __init__(self, entity_cls: type[T], db_session: Any):
        super().__init__()
        self._entity_cls = entity_cls
        self._db_session = db_session

    def get(self, pkey: str) -> T:
        ...

    def create(self, value: T) -> T:
        ...


class DB:
    def __init__(self, db_session: Any):
        super().__init__()
        self._db_session = db_session

    def store_of(self, entity_cls: type[T]) -> Store[T]:
        return Store(entity_cls=entity_cls, db_session=self._db_session)

    @my_decorator
    def my_decorated_store_of(self, entity_cls: type[T]) -> Store[T]:
        return Store(entity_cls=entity_cls, db_session=self._db_session)

    @lru_cache
    def cached_store_of(self, entity_cls: type[T]) -> Store[T]:
        return Store(entity_cls=entity_cls, db_session=self._db_session)


class Account:
    ...


typing.reveal_type(DB(db_session="connection").store_of(entity_cls=Account))
account_store_1: Store[Account] = DB(db_session="connection").store_of(
    entity_cls=Account,
)

typing.reveal_type(DB(db_session="connection").my_decorated_store_of(entity_cls=Account))
account_store_2: Store[Account] = DB(db_session="connection").my_decorated_store_of(
    entity_cls=Account,
)

typing.reveal_type(DB(db_session="connection").cached_store_of(entity_cls=Account))
account_store_3: Store[Account] = DB(db_session="connection").cached_store_of(
    entity_cls=Account,
)

Version

❯ pyright --version  
pyright 1.1.356

Output
❯ pyright generic_bug.py
/Users/shawn/Code/instance-bio/instance/services/web/generic_bug.py
/Users/shawn/Code/instance-bio/instance/services/web/generic_bug.py:51:20 - information: Type of "DB(db_session="connection").store_of(entity_cls=Account)" is "Store[Account]"
/Users/shawn/Code/instance-bio/instance/services/web/generic_bug.py:54:20 - information: Type of "DB(db_session="connection").my_decorated_store_of(entity_cls=Account)" is "Store[Account]"
/Users/shawn/Code/instance-bio/instance/services/web/generic_bug.py:59:20 - information: Type of "DB(db_session="connection").cached_store_of(entity_cls=Account)" is "Store[T@cached_store_of]"
/Users/shawn/Code/instance-bio/instance/services/web/generic_bug.py:60:35 - error: Expression of type "Store[T@cached_store_of]" cannot be assigned to declared type "Store[Account]"
  "Store[T@cached_store_of]" is incompatible with "Store[Account]"
    Type parameter "T@Store" is invariant, but "T@cached_store_of" is not the same as "Account" (reportAssignmentType)
1 error, 0 warnings, 3 informations

[strangemonad]

This might have the same cause as #2133. typeshed seems to annotate lru_cache as Callable[..., _T]. The the case of call-sites of decorated methods, would it be sensible for pyright to attempt to capture the call signature and do inference similar to how regular method type inference is implemented rather than treat ... as type erasure? I'm not sure if there's a clean way to change typeshed to use ParamSpecVariable and unpack that to infer the generic return type in this case.

[erictraut]

This appears to be a duplicate of #6668. Please file a bug in the typeshed project if you don't like the way that lru_cache is defined in the typeshed stubs. I personally think that the current definition creates more problems than it solves, so I would be in favor of changing it, but to do that you'll need to convince the typeshed maintainers.

[strangemonad]

thanks @erictraut. I'll follow up with typeshed. I know there's a handful of issues and some history with the evolution of ParamSpec and possibly some corner cases where ParamSpec wasn't sufficient.

[erictraut]

Here's a link to an issue in typeshed that discusses some of the tradeoffs: python/typeshed#11280. The current definition of cache and lru_cache focuses on catching errors where the parameters are not hashable. It does this at the expense of destroying the function signature, which creates many problems. From my perspective, it would be better to preserve the function signature and give up on catching non-hashable parameters, but it's a difficult tradeoff.