`final` overrides not detected on methods decorated with `cache`

[eachimei]

In the below example we expect pyright to flag all 3 overrides as violations due to all methods decorated with @final in the base-class. However, only simple is flagged:

from functools import cache
from typing import final


class Parent:

    @final
    def simple(self):
        ...

    @final
    @cache
    def final_over_cache(self):
        ...

    @cache
    @final
    def cache_over_final(self):
        ...


class Child(Parent):

    def simple(self):
        ...

    @cache
    def final_over_cache(self):
        ...

    @cache
    def cache_over_final(self):
        ...

Output:

>pyright pyright_final.py
pyright_final.py
  pyright_final.py:24:9 - error: Method "simple" cannot override final method defined in class "Parent" (reportIncompatibleMethodOverride)
1 error, 0 warnings, 0 informations

Version information:
Python 3.10.11
pyright 1.1.401

[erictraut]

The cache decorator returns an object of type _lru_cache_wrapper, transforming the final method into an object. It's equivalent to:

class Child(Parent):

    @final
    def _final_over_cache(self):
        ...

    final_over_cache = cache(_final_over_cache)

The final attribute of the method is lost in this transformation process.

I'll investigate whether it's feasible to add special-case logic to handle this case, but I may end up closing this issue.

[eachimei]

Thank you for the prompt response!
Do you believe (in case a special-case/workaround is not feasible) that an issue should be filed for CPython-functools itself?

[erictraut]

an issue should be filed for CPython-functools itself

This isn't a runtime issue, so there's nothing to fix in the runtime implementation of functools.cache. It's more an issue with the way that cache is defined in the functools.pyi typeshed stub. There's a long-running debate in the typeshed project about how cache and lru_cache should be defined. You can read about it here. I'm in favor of changing the typeshed definitions here, but the typeshed maintainers have not reached consensus that such a change would be preferable. There are tradeoffs — namely, you lose the ability to statically enforce hashability of the parameters of the decorated function. If you'd like to weigh in on this topic, I recommend responding to that thread.

[eachimei]

Thank you very much, I'll catch up on the thread!

[erictraut]

This is addressed in pyright 1.1.402.

[eachimei]

Awesome, thanks!