Decorated property not supported

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.

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

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?

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

Thanks for the clarification.

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.

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.

[DEM-943] Decorated property not supported (python/mypy#1362).

Soon, follow #13385

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?

(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): ...

?

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

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.

@bew

@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.

mypy: silent property setter error (see python/mypy#1362)

replace @decorated_property decorator

Bump mypy version

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)

Ignore mypy error

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

Navigation Menu

Repository navigation

Decorated property not supported #1362

59 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Decorated property not supported #1362

Description

Activity

gvanrossum commented on Apr 11, 2016

nullp0tr commented on Feb 19, 2018

gvanrossum commented on Feb 19, 2018

nullp0tr commented on Feb 20, 2018

OJFord commented on Nov 13, 2018

gvanrossum commented on Nov 13, 2018

59 remaining items

hauntsaninja commented on Sep 19, 2022

analog-cbarber commented on Oct 20, 2022

bew commented on Oct 20, 2022

analog-cbarber commented on Oct 20, 2022

leycec commented on Oct 21, 2022

OJFord commented on Oct 21, 2022

samskiter commented on Dec 9, 2023

hhartzer commented on Mar 12, 2024

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions