You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Regarding a) this is not really about typing, technically property is a class, so you can annotate your decorator as just -> property. Some type checkers may be not happy about this, but then it should be discussed per type checker.
About b) we can add some special casing for property but this is a more general problem, unless decorator copies the __annotations__ attribute, we can't do much.
@earonesty Thank you for putting me on the right path...
I was looking for this trick for so long, I think I should share it here.
Before reaching fget or fset attributes from a property, we need to access descriptor statically either from inspect.getattr_static() or type.__getattribute__(), otherwise Python would raise AttributeError: 'FooBar' object has no attribute "fget" since it is trying to access 'fget' on property return value instead of the object itself.
I mean for me it would make sense the most to actually annotate the return type for the function the property calls, and maybe the property could automatically adapt to that?
@propertydeffoo(...) ->int:
to
Union[property, int]
or that a new type idea
Property[int]
Like as long as you annotate the function under the @property that could automatically be used?
Here's a real-world example for where a generic property is required (screenshots included for easier reference).
Response.vary is property[HeaderSet], but without the ability to provide a generic type, static type checkers interpret it as Any. When I use response.vary.add('Accept') in my code, there's no type check for the add method:
Since in #985 it considered too difficult to make builtins.property generic, a substitute typing.Property will be most excellent.
I don't think we will add typing.property if builtins.property exists. There has been a trend towards deprecating this kind of duplication, i.e. making built-in types generic. This would be the correct course of action for property as well, even if it proves difficult.
Activity
ilevkivskyi commentedon Nov 20, 2018
Regarding a) this is not really about
typing, technically property is a class, so you can annotate your decorator as just-> property. Some type checkers may be not happy about this, but then it should be discussed per type checker.About b) we can add some special casing for
propertybut this is a more general problem, unless decorator copies the__annotations__attribute, we can't do much.[-]@property support[/-][+]Can't access __annotations__ on a @property[/+]earonesty commentedon May 8, 2020
FYI: if you wind up here, you can do this for now:
TangoMan75 commentedon May 13, 2020
@earonesty Thank you for putting me on the right path...
I was looking for this trick for so long, I think I should share it here.
Before reaching
fgetorfsetattributes from a property, we need to access descriptor statically either frominspect.getattr_static()ortype.__getattribute__(), otherwise Python would raiseAttributeError: 'FooBar' object has no attribute "fget"since it is trying to access 'fget' on property return value instead of the object itself.jp-larose commentedon Sep 3, 2020
Could we have a generic Property class added to
typing? PEP 614 would allow something like this:Here's the gist of the class I'm proposing (details will likely need to be refined):
luckydonald commentedon Sep 3, 2020
I mean for me it would make sense the most to actually annotate the return type for the function the property calls, and maybe the property could automatically adapt to that?
to
or that a new type idea
Like as long as you annotate the function under the
@propertythat could automatically be used?[-]Can't access __annotations__ on a @property[/-][+]Add typing.Property[/+]jace commentedon Jun 3, 2024
Here's a real-world example for where a generic property is required (screenshots included for easier reference).
Response.varyisproperty[HeaderSet], but without the ability to provide a generic type, static type checkers interpret it asAny. When I useresponse.vary.add('Accept')in my code, there's no type check for theaddmethod:Since in #985 it considered too difficult to make
builtins.propertygeneric, a substitutetyping.Propertywill be most excellent.https://github.com/pallets/werkzeug/blob/3.0.3/src/werkzeug/sansio/response.py#L40-L61
srittau commentedon Jun 3, 2024
I don't think we will add
typing.propertyifbuiltins.propertyexists. There has been a trend towards deprecating this kind of duplication, i.e. making built-in types generic. This would be the correct course of action forpropertyas well, even if it proves difficult.