Failure to recognize type of descriptor attribute declared inline

[couteau]

I'm posting this here before filing an issue to be sure this is actually a Pyright issue and that others agree it is a big and not an enhancement request. The issue is that when I declare a class attribute with a type hint and set it equal to a descriptor class instance inline (rather than using a decorator to create the descriptor), and then define a setter, vs code/pyright see the attribute on the instance as a method (specifically, the setter method). Here is an example using the builtin property descriptor:

class TestClass:
    field: list[str] = property(lambda s: s._field)

    @field.setter
    def field(self, value: list[str]):
        self._field = value


c = TestClass()
c.field = ['hello', 'tester']

for s in c.field:
    print(s.upper())


class TestClass2:
    field: list[str]

    @property
    def field(self):
        return self._field
    
    @field.setter
    def field(self, value: list[str]):
        self._field = value

d = TestClass2()
d.field = ['greetings', 'tester']

for s2 in d.field:
    print(s2.upper())

In the first instance, where the property is created inline using a lambda as the getter, upright only sees the setter method, and when I then try to iterate the field attribute (or use it in any other way where I want its type to be recognized), pyright doesn't see it as an utterable and doesn't recognize the type of its elements. The result is, I don't get intellisense help on the methods of the element (in the example, the string's upper method). In the second example, where the property is created using a descriptor to define the getter, it works as expected. The field attribute is recognized as a list of str and its elements are recognized as strings with all the built-in string methods.

Obviously, this is a contrived example--there would be no reason to define a generic property using a lambda. My actual descriptors are more complex, but the problem is the same.

So is this a Pyright issue? Is it a bug, or am I looking for an enhancement?

[erictraut]

Pyright is working as intended here, so I don't consider this a bug. This is also not something that we'd be likely to entertain as an enhancement request.

Static type checkers need to do significant special-casing for the builtin property class. You're using it in a manner that static type checkers (like pyright or mypy) will not be able to handle. If you want this code to work with static type checking, you'll need to make modifications to your code.

Also, a property is not the same as a simple attribute, so overriding a property with a simple attribute or vice versa in a subclass is not type safe.

Here's the type safe variant that works with static type checkers:

class TestClass:
    @property
    def field(self) -> list[str]:
        return self._field

    @field.setter
    def field(self, value: list[str]):
        self._field = value

c = TestClass()
c.field = ["hello", "tester"]

for s in c.field:
    print(s.upper())

class TestClass2:
    @property
    def field(self):
        return self._field

    @field.setter
    def field(self, value: list[str]):
        self._field = value

d = TestClass2()
d.field = ["greetings", "tester"]

for s2 in d.field:
    print(s2.upper())

[couteau]

Hi - circling back here because I think there is an inconsistency in the handling of properties, as shown in this slightly different example.

class TestClass1:
    myproperty: list[str] = property(lambda s: s._myproperty)

class TestClass2:
    myproperty: list[str] = property(lambda s: s._myproperty)

    @myproperty.setter
    def myproperty(self, value: list[str]):
        self._myproperty = value

The only difference in these classes is the addition of the setter on an existing property. In the first case, Pyright recognizes myproperty as a property with the type list[str]. In the second, it sees it a s a method returning none. I.e., the setter hides the property, which it doesn't do when the property is first declared using a decorator. I understand that I can work around the issue by always using a decorator to declare the property, but that requires additional boilerplate for simple properties that return a private attribute.