Mypy: Decorated property not supported

[pyrocat101]

class Foo(object):
    @property
    @some_decorator
    def foo(self):
        ...

is valid in Python 2, but MyPy complains Decorated property not supported.
Adding type: ignore does not ignore the error.

[gvanrossum]

Good news: if you put the # type: ignore on the @property line it's silent.

[nullp0tr]

A bit off topic, but I came across this warning today and it made me wonder about something. I have a BLE Connection class, and each instance has the attributes characteristics and services, which are implemented with the @property decorator so that it can actually fetch them a new every time without assigning a lambda or making them a method. Fetching can raise an exception though, and I'm wondering how normal is it that something like "a = b.attribute" can raise an exception that can't be just avoided by rearranging the code like from a NameError or a SyntaxError?

[gvanrossum]

Since properties are common in Python, that's not something to be concerned about.

[nullp0tr]

Thanks for the clarification.

[OJFord]

Good news: if you put the # type: ignore on the @property line it's silent.

Note it appears to need to be on the outer decorator, so if you have the opposite order to OP:

@some_decorator
@property
def foo

then it should be on the @some_decorator line.

[gvanrossum]

Correct, messages related to a function (or, sometimes, its arguments)
always appear on the line of the first decorator, if there is one,
otherwise on the linke containing 'def'. (I consider this a slight flaw, as
occasionally it makes it hard to find the root cause for an error message.)

The rule "put the '# type: ignore' on the line where the error appears" is
pretty simple to remember though.

[ZahlGraf]

Hello

I have the same issue. In my project I use additional decorators for properties very often. Thus mypy sends me hundreds of error with "error: Decorated property not supported".

First of all, I don't understand the error message. Does it mean mypy does not support decorated properties, or is decorating a property related to any code quality issue in general? Because if just mypy is not supporting decorated properties, but the pattern in general is not considered as bad practice, I don't know, why mypy is giving me an error here. It should be at maximum a warning right?

Second, if it is just a mypy issue, I really want to ignore it. Is there any way to ignore exactly this error on a global level? At the moment, I'm only aware of ignoring type errors for a single line, but since this pattern is extremely common in my code, I don't want to add the "ignore line" comment on hundreds of lines in my code.

Thanks in advance for any suggestions and assistance.

[JukkaL]

Mypy cannot properly type check code involving decorated properties. Currently there's no way to ignore all such errors, but this is something mypy may support in the future.

As a workaround, you could try defining your own alias to the property decorator that is annotated to return Any. If you use your custom property decorator (that at runtime behaves exactly like property) for all decorated properties, mypy will silently give all such properties the Any type.

[kawing-chiu]

Same issue here. I have to use decorated property because the abc module have deprecated @abstractproperty. The only way to define an abstract property is to use decorated property:

class C(ABC):
    @property
    @abstractmethod
    def my_abstract_property(self):
        ...

    @my_abstract_property.setter
    @abstractmethod
    def my_abstract_property(self, val):
        ...

If generally decorated properties cannot be supported, can mypy special-case and support @abstractmethod?

[ilevkivskyi]

If generally decorated properties cannot be supported, can mypy special-case and support @abstractmethod?

Yes, this (supporting abstract settable properties) is actually what is done by PR https://github.com/python/mypy/pull/8111 (it is a few line fix I added because this broke couple tests for the main PR matter).

[warsaw]

Same issue here. I have to use decorated property because the abc module have deprecated @abstractproperty. The only way to define an abstract property is to use decorated property:

class C(ABC):
    @property
    @abstractmethod
    def my_abstract_property(self):
        ...

    @my_abstract_property.setter
    @abstractmethod
    def my_abstract_property(self, val):
        ...

If generally decorated properties cannot be supported, can mypy special-case and support @abstractmethod?

This is exactly my use case too.

[analog-cbarber]

Wish there was some easy way to mark the decorator function to tell mypy to ignore it or a way to tell mypy to always ignore such decorators.

It is really ugly to have to slap a # type: ignore comment on every use of a property decorator.

Let's put it this way: what is the concrete benefit of the existing behavior?

[Fokko]

Same here :)

[MicaelJarniac]

What's the progress on this issue?

I'm using the @functools.lru_cache decorator on many @property methods and this "warning" shows up on them all.

from functools import lru_cache

class MyClass:
    def __init__(self, year: int):
        self.current_year = 2020
        self.year = year

    @property  # Decorated property not supported - mypy(error)
    @lru_cache
    def how_long_ago(self) -> int:
        return self.current_year - self.year

I'm using the "workaround" of adding # type: ignore, but it's far from ideal.

from functools import lru_cache

class MyClass:
    def __init__(self, year: int):
        self.current_year = 2020
        self.year = year

    @property  # type: ignore
    @lru_cache
    def how_long_ago(self) -> int:
        return self.current_year - self.year

functools should have a @cached_property decorator that would probably not trigger this "warning" from mypy, but it's only for Python ≥ 3.8, and I'm currently stuck on Python ≤ 3.7, so I can't use it.

from functools import cached_property

class MyClass:
    def __init__(self, year: int):
        self.current_year = 2020
        self.year = year

    @cached_property  # Python >= 3.8
    def how_long_ago(self) -> int:
        return self.current_year - self.year

Update

For my specific use case, I believe the following could do the trick:

try:
    from functools import cached_property
except ImportError:
    from functools import lru_cache

    def cached_property(func):  # type: ignore
        return property(lru_cache(func))

class MyClass:
    def __init__(self, year: int):
        self.current_year = 2020
        self.year = year

    @cached_property
    def how_long_ago(self) -> int:
        return self.current_year - self.year

And I believe this pattern of combining common decorators can also apply to other use cases.
https://stackoverflow.com/questions/5409450/can-i-combine-two-decorators-into-a-single-one-in-python

[rookwood101]

As a workaround, you could try defining your own alias to the property decorator that is annotated to return Any. If you use your custom property decorator (that at runtime behaves exactly like property) for all decorated properties, mypy will silently give all such properties the Any type.

For others' reference, this can be done like so:

def property(fn) -> Any:
    """Resolves mypy 'error: Decorated property not supported'"""
    return property(fn)