User invisible decorators should not trigger Protocol type conflicts. #10502

Whether this is a bug report or an enhancement request depends on whether the current behavior is as designed.

The unwanted behavior

Let me illustrate the behavior I am talking about with very contrived example. The error is reported for the def mass in the Spam class (line 26).

from functools import cache
from typing import Protocol


class SupportsMass(Protocol):
    @property
    def density(self) -> float:
        """Grams per milliliter."""
        ...

    def mass(self, volume: float) -> float:
        """Mass of object in grams given volume in milliliters."""
        ...


class Spam(SupportsMass):
    def __init__(self) -> None:
        # Spam is allegedly 237 grams per metric cup.
        self._density = 237 / 240  # g/ml

    @property
    def density(self) -> float:
        return self._density

    @cache
    def mass(self, volume: float) -> float:  # pyright reports error here
        return volume * self._density

Running pyright on that file yields this:

% pyright cache_protocol.py      
/PATH_TO/cache_protocol.py
  /PATH_TO/cache_protocol.py:26:9 - error: "mass" overrides method of same name in class "SupportsMass" with incompatible type "_lru_cache_wrapper[float]" (reportIncompatibleMethodOverride)
1 error, 0 warnings, 0 informations

I do understand that using the @cache decorator from functools changes the type of mass(), but it doesn't do so from the perspective of the user of the protocol and the class. That is, the use of a decorator like @cache is an implementation detail of the Spam class that should not be relevant for the protocol.

Contrast this with @property for density(), where it has a direct impact on how the method is to be called. Pyright behaves correctly in insisting that the decorator be specified the same in both the definition of the protocol and in the definition of a subclass of the protocol.

Note: if you are reporting a wrong signature of a function or a class in the standard library, then the typeshed tracker is better suited for this report: https://github.com/python/typeshed/issues.

If you have a question about typing or a behavior that you’re seeing in Pyright (as opposed to a bug report or enhancement request), consider posting to the Pyright discussion forum.

VS Code extension or command-line

I first noticed the behavior within VS Code, but I have reproduced on the command-line

% pyright --version
pyright 1.1.401
% python --version
Python 3.13.3