Decorated property not supported #1362
Description
Activity
Good news: if you put the
# type: ignoreon the@propertyline it's silent.Reacted by Maciej Olko, Andrew Yurisich, Jan Freyberg, Maurício Eduardo Loschi Batista, Aziz Alto, MercyPrasanna, Donghyun (Anthony) Kim, Eero Ruohola, Stefano Pettini, Boris Pavlovic and 8 more- added this to the milestone
on Apr 11, 2016 - removed this from the milestone
on Mar 29, 2017 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: ignoreon the@propertyline 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 foothen it should be on the
@some_decoratorline.- 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.
59 remaining items
Soon, follow #13385
Reacted by Benoit de Chezelles, Cecil Curry and Will Da SilvaSo 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): ...
?
Reacted by Marcel Jackwerth, Oliver Ford and Cecil CurryThat would not be correct. My decorator takes a property and returns a property. It is decorating the property and not the function.
Reacted by Oliver Ford, Cecil Curry, Samuel Colvin and Kevin KirscheReacted by Benoit de Chezelles and Cecil CurryYup. @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.- added a commit that references this issue
on Jan 12, 2023 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)
Reacted by Daniele Isoni, thibaut-lo, Anatoly, Wizzerinus | Alex K. and George BurtonCould someone explain why this is closed? It still seems to be an issue.
- locked as resolved and limited conversation to collaborators
on Mar 12, 2024
is valid in Python 2, but MyPy complains
Decorated property not supported.Adding
type: ignoredoes not ignore the error.