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.

[leycec]

Gah! How is this possibly still an issue in late 2022? It's literally been eight years. Sad panda is sad.

[graingert]

Gah! How is this possibly still an issue in late 2022? It's literally been eight years. Sad panda is sad.

Afaik it's fixed in the master branch

[bew]

Any idea when will be the next release with this change?

[hauntsaninja]

Soon, follow #13385

[analog-cbarber]

So now there is just a new useless error. Now I get "Decorators on top of @Property are not supported".

What purpose does this error serve?

[bew]

(edit: well, looks like that's not wanted `¯\_(ツ)_/¯`, I tried)

The comment I tried to suggest:

Try changing

@your_decorator
@property
def foo(self): ...

to

@property
@your_decorator
def foo(self): ...

?

[analog-cbarber]

That would not be correct. My decorator takes a property and returns a property. It is decorating the property and not the function.

[leycec]

Yup. @beartype transparently supports both modalities, too – including direct decoration of high-level property getters, setters, and deleters as well as of lower-level methods subsequently decorated as property getters, setters, and deleters. Decoration order is irrelevant (as it should be): e.g.,

from beartype import beartype

class FunWithHungryBears(object):
    # This is fine.
    @beartype
    @property
    def feed_bear_garbage() -> str:
        return 'Bear responds by tearing apart garbage.'

    # This is fine, too.
    @property
    @beartype
    def throw_salmon_at_bear() -> str:
        return 'Bear responds by opening spittle-flecked muzzle.'

Thank Guido for # type: ignore. Through ignorance, we pretend mypy is sane.

[OJFord]

@bew Your suggestion was semantically different - imagine mypy didn't work with list arguments for some reason, 'try using a set instead' wouldn't really be a solution.

[samskiter]

Soon, follow #13385

Still not fixed and appears as a gotcha in the pydantic docs: https://docs.pydantic.dev/2.0/usage/computed_fields/

(On mypy v 1.5.1)

[hhartzer]

Could someone explain why this is closed? It still seems to be an issue.