"class property" should be Generic[T]

Currently property.__get__ returns Any, which loose information:

Line 877 in c58a93b

class property(object):

This would be more correct for property.__get__ to be generic and return T. Similar to cached_property:

Line 113 in 1dd1b70

class cached_property(Generic[_T]):

class A:

  @cached_property
  def f(self) -> int:  # f is `cached_property[int]`, f.__get__() -> int
    ...

  @property
  def g(self) -> int:  # f is `property[Any]`, g.__get__() -> Any
    ...

This makes sense to me. It might even make sense to use two type variables for setting and getting. On the other hand, I don't know what the impact on type checkers is, since I think they usually hard-code properties.

I was going to open a new issue in response to python/typing#758, but found this one already opened :)

I seriously doubt this is idea is supported, but I'll ask anyway.... Is it possible to @overload a class like you can for a function/method? The reason I thought of that is it would allow property with one or two TypeVars. I suspect that the vast majority of uses is for the getter and setter of property to use the same type. However, for those cases where they use different types, there needs to be some way to express that.

@overload
class property(Generic[_T]):
    fget: Optional[Callable[[Any], _T]]
    fset: Optional[Callable[[Any, _T], None]]
    fdel: Optional[Callable[[Any], None]]
    .... # The remaining signatures


@overload
class property(Generic[_T_contra, _T_co]):
    fget: Optional[Callable[[Any], _T_co]]
    fset: Optional[Callable[[Any, _T_contra], None]]
    fdel: Optional[Callable[[Any], None]]
    .... # The remaining signatures

You can overloads its __init__ or __new__ method.

Though I guess that wouldn't give you a way to vary the number of type parameters.

@erictraut

How about something like this?

_C = TypeVar("_C", contravariant=True)
_R = TypeVar("_R", covariant=True)
_R2 = TypeVar("_R2", covariant=True)
_V = TypeVar("_V", contravariant=True)
_V2 = TypeVar("_V2", contravariant=True)

class property(Generic[_C, _R, _V]):
    fget: Callable[[_C], _R] | None
    fset: Callable[[_C, _V], None] | None
    fdel: Callable[[_C], None] | None
    __isabstractmethod__: bool
    def __init__(
        self,
        fget: Callable[[_C], _R] | None = ...,
        fset: Callable[[_C, _V], None] | None = ...,
        fdel: Callable[[_C], None] | None = ...,
        doc: str | None = ...,
    ) -> None: ...
    def getter(self, __fget: Callable[[_C], _R2]) -> property[_C, _R2, _V]: ...
    def setter(self, __fset: Callable[[_C, _V2], None]) -> property[_C, _R, _V2]: ...
    def deleter(self, __fdel: Callable[[_C], None]) -> property: ...
    def __get__(self, __obj: _C | None, __type: Type[_C] | None = ...) -> Any: ...
    def __set__(self, __obj: _C, __value: _V) -> None: ...
    def __delete__(self, __obj: _C) -> None: ...

Since the undefined type vars default to Never when they are not provided, this should work fine.

I'm happy to create a pull request if this is something that would potentially be accepted. What do you guys think?

Edit: After writing this, I realized that @erictraut has written something similar

Perhaps add overloads for __get__?

@overload
def __get__(self, instance: _C, owner: type[_C] | None = ..., /) -> _R: ...
@overload
def __get__(self, instance: None, owner: type[_C], /) -> Self: ...

Also I think the title of this issue is pretty misleading ("class properties" were deprecated in Python 3.11). I will await feedback and possibly make a PR, since the ecosystem must have changed a lot in the five years since the last PR, but there is still sure to be much breakage.

I think that we are going to need this in PEP 827 - Type Manipulation (https://peps.python.org/pep-0827/), for representing the types of properties.

An exploratory PR would certainly be welcome. Type var defaults should also make the implementation backwards-compatible nowadays. But I would seriously consider using separate output and an input type vars. (Unfortunately, the type systems doesn't supports defaulting one type var to another, as far as I know.)

PEP 696 does support having one TypeVar default to another.

To fully represent the possible states of a property, we'd also need to represent whether or not there is a deleter, and also whether there is a setter and getter. Though for the latter two, there is little practical difference between "setter that accepts Never" and "no setter", so we could just use Never for the setter type. And as for the deleter, that very rarely matters.

Navigation Menu

Repository navigation

"class property" should be Generic[T] #4731

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

"class property" should be Generic[T] #4731

Description

Activity

srittau commented on Nov 3, 2020

jp-larose commented on May 18, 2021

jp-larose commented on May 18, 2021

JelleZijlstra commented on May 18, 2021

JelleZijlstra commented on May 18, 2021

davidhalter commented on Mar 9, 2023

jonathandung commented on Jul 7, 2026

msullivan commented on Oct 23, 2026

srittau commented on Oct 23, 2026

JelleZijlstra commented on Oct 24, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions