class with __setattr__ reports properties are read-only

[rhshadrach]

When a class implements __setattr__, mypy still reports properties as read-only.

Minimum example:

class Foo:
    def __init__(self) -> None:
        self._d = {'a': 1}

    def __setattr__(self, name: str, value: Any) -> None:
        if hasattr(self, '_d'):
            self._d[name] = value
        else:
            super(self.__class__, self).__setattr__(name, value)

    @property
    def a(self) -> int:
        return self._d['a']

f = Foo()
f.a = 2

The error points to the last line in the above code: error: Property "a" defined in "Foo" is read-only.

Expectation: Since Foo implements __setattr__, mypy should allow the attribute to be set, even though it overlaps with a class property.

There are no issues identified if the property a is removed, and I am using version 0.781.

[JukkaL]

Yeah, this looks like false positive.

[JukkaL]

Anybody want to contribute a fix -- it should be easy?

Add a check about __setattr__ in mypy.checkmember.analyze_var (before the call to mx.msg.read_only_property).

[kamilturek]

@JukkaL I can take care of this.

[hauntsaninja]

I reverted the fix #9196 in #9474. Copying my comment from the revert:

...

I realised that object in typeshed has __setattr__ defined. It's a pretty common idiom for marking read-only attributes using properties, and since every class has a __setattr__ in its MRO, this breaks that.

E.g, this would no longer produce an error:

from datetime import date
dt = date(2000, 1, 1)
dt.year = 2003

Additionally, it introduces a broken test on master, since we (unintentionally) don't run some Python2 tests in CI (filed as #9473 )

...

I'm not sure what the path forward is. Maybe it's okay to merge a version that doesn't check the MRO (as in the original PR), or maybe we exclude object's __setattr__ from the check. cc @kamilturek @JukkaL

[rhshadrach]

Thanks for the details @hauntsaninja. Even if __setattr__ is defined on a class, it may still not allow setting properties, for which I can see users wanting mypy to still identify this as an error. I don't quite see a way for mypy to tell the difference here (but I know really nothing about how mypy internals work).

Here is my workaround; it allows for:

• Settable properties to be handled using a single function (my use-case).
• mypy to differentiate between a settable and non-settable property.

mypy will identify the last line as an error, but not the penultimate line.

def settable_property(s):
    def mysetattr(self, value):
        name = s.__name__
        if hasattr(self, f'_{name}'):
            setattr(self, f'_{name}', value)
        else:
            super(self.__class__, self).__setattr__(name, value)

    return property(s, mysetattr)


class Foo:
    def __init__(self) -> None:
        self._a = 1

    @settable_property
    def a(self) -> int:
        return self._a

    @property
    def b(self) -> int:
        return self._a


f = Foo()
f.a = 2
f.b = 2

[hauntsaninja]

I haven't seen much request for this feature in the intervening years, and I think fixing the false positive here would hurt many more common cases.