Mypy disallows overriding an attribute with a property

[rowillia]

For example:

class Foo:
    def __init__(self) -> None:
        self.x = 42

class Bar(Foo):
    def __init__(self) -> None:
        self.y = 9000

    @property
    def x(self) -> int:
        print('got x!!!')
        return self.y

    @x.setter
    def x(self, value: int) -> None:
        print('set x!!!')
        self.y = value

This should be allowed as it doesn't violate LSP as long as x implements both a getter and a setter of the correct type.

[ilevkivskyi]

Hm, interesting, this is already allowed for structural subtypes:

class Foo(Protocol):
    x: int

class Bar:
    def __init__(self) -> None:
        self.y = 9000

    @property
    def x(self) -> int:
        print('got x!!!')
        return self.y

    @x.setter
    def x(self, value: int) -> None:
        print('set x!!!')
        self.y = value

x: Foo = Bar() # OK

I think this is a bug, it should be allowed for nominal classes as well.

[JukkaL]

Yes, this is a bug. I was under the impression that this was already working.

[elazarg]

Technically it does violate LSP; there should be a warning about the missing @x.deleter.

[emmatyping]

Yes, but if you add a deleter it still complains.

[JelleZijlstra]

I don't think mypy should actually care about whether a deleter is present though, since deleting attributes is rare and if you do it your code is unlikely to be type-safe anyway.

[elazarg]

True, but overriding an attribute with a property is also not so common, so a reminder that it's not complete might be useful.

[srittau]

There is a different error message when using property() as a function:

class Base:
    prop: bool

class Sub(Base):
    def _get_prop(self) -> bool:
        return False
    def _set_prop(self, value: bool) -> None:
        pass
    prop = property(_get_prop, _set_prop)

foo.py:9: error: Incompatible types in assignment (expression has type "property", base class "Base" defined the type as "bool")

[erickpeirson]

In mypy==0.720, if I slightly modify the example in #4125 (comment) (above) based on the documentation's guidance that:

Explicitly including a protocol as a base class is also a way of documenting that your class implements a particular protocol, and it forces mypy to verify that your class implementation is actually compatible with the protocol.

...I get the following behavior:

class Foo(Protocol):
    x: int

class Bar(Foo):
    def __init__(self) -> None:
        self.y = 9000

    @property            # Signature of "x" incompatible with supertype "Foo"
    def x(self) -> int:  # Signature of "x" incompatible with supertype "Foo"
        print('got x!!!')
        return self.y

    @x.setter
    def x(self, value: int) -> None:
        print('set x!!!')
        self.y = value

x: Foo = Bar()

I would expect this to be OK for the same reasons that the original protocol example (no inheritance) is OK.

[ilevkivskyi]

Setting priority to high, see duplicate issue #6759 (comment) for motivation.

[ziima]

I ran into a similar issue. Mypy seems to disallow overriding even a property, if not defined using a decorator:

# Annotations in here doesn't seem to matter.
def _not_implemented(*args, **kwargs):
    raise NotImplementedError


class AbstractClass:
    foo = property(_not_implemented, _not_implemented)


class MyClass(AbstractClass):
    # Here the mypy reports:
    # error: Signature of "foo" incompatible with supertype "AbstractClass"  [override]
    @property
    def foo(self) -> str:
        return 'Foo'

    @foo.setter
    def foo(self, value: str) -> None:
        pass

If AbstractClass.foo is defined with property as a decorator, it works fine.

[ramalho]

True, but overriding an attribute with a property is also not so common, so a reminder that it's not complete might be useful.

I disagree. Overriding an attribute with a property is a recommended best practice. You start your class with public attributes, and if a subclass needs some getter or setter logic, then you make it into a property. I agree that, pragmatically the lack of a deleter is not relevant in practice, and should be ignored.

The following advice appears in Alex Martelli's classic and highly influential Python in a Nutshell since the first edition:

The crucial importance of properties is that their existence makes it perfectly safe (and indeed advisable) for you to expose public data attributes as part of your class’s public interface. Should it ever become necessary, in future versions of your class or other classes that need to be polymorphic to it, to have some code executed when the attribute is referenced, rebound, or unbound, you know you will be able to change the plain attribute into a property and get the desired effect without any impact on any other code that uses your class (AKA “client code”). This lets you avoid goofy idioms, such as accessor and mutator methods, required by OO languages that lack properties or equivalent machinery.

some_instance.widget_count += 1

rather than being forced into contorted nests of accessors and mutators such as:

some_instance.set_widget_count(some_instance.get_widget_count() + 1)

[erictraut]

For what it's worth, pyright does not allow attributes to be overridden with properties or vice versa. Our reasoning is that the semantics for an attribute are not the same as a property. In the sample at the top of this issue, for example, the attribute would work with del but the property would not. From a type safety perspective, it is not safe to substitute one for the other.

[ramalho]

Thanks for your insight, @erictraut. That's yet another situation where "type safety" trumps established practices in Python. It makes me think everyone would be happier if there was a derivative language with static types—which was @JukkaL's original idea for Mypy. Yet another lesson to learn from TypeScript.

[chadrik]

Isn’t the idea of deleting attributes antithetical to static typing? If I’m using mypy to check my code, deleting attributes is not something I want to accommodate, especially at the detriment of a useful *typing* feature like overriding an attribute with a property. In fact, it’s not hard to imagine that deleting an attribute should be considered a type error.

…

On Mon, Jun 28, 2021 at 7:33 PM Luciano Ramalho ***@***.***> wrote: Thanks for your insight, @erictraut <https://github.com/erictraut>. That's yet another situation where "type safety" trumps established practices in Python. It makes me think everyone would be happier if there was a derivative language with static types—which was @JukkaL <https://github.com/JukkaL>'s original idea for Mypy. Yet another lesson to learn from TypeScript. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4125 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPOE4FJXR4ZQFCKQLMKX3TVEIENANCNFSM4D7NBVTQ> .

[ramalho]

Same with adding attributes at runtime, which is a feature, not a bug of Python and dynamic languages in general. But with time, the widespread, uncritical use of type hints will make those language features become taboo, and then you have—in effect—a different language defined by different usage reinforced by tooling. Which is why a derivative with a different name communicates better. TypeScript, not JavaScript with types bolted on.

[GBeauregard]

There's a workaround that works for both mypy and pyright if you're willing to use descriptors. Method follows typing advice from https://twitter.com/AdamChainz/status/1450044899093618688

from __future__ import annotations

from typing import cast, overload


class YIntProp(int):
    @overload
    def __get__(self, obj: None, objtype: None) -> YIntProp:
        ...

    @overload
    def __get__(self, obj: object, objtype: type[object]) -> int:
        ...

    def __get__(
        self, obj: object | None, objtype: type[object] | None = None
    ) -> YIntProp | int:
        if obj is None:
            return self
        return cast(int, obj.__dict__["y"])

    def __set__(self, obj: object, value: int) -> None:
        obj.__dict__["y"] = value


class Foo:
    def __init__(self) -> None:
        self.x = 42


class Bar(Foo):
    x = YIntProp()

    def __init__(self) -> None:
        self.y = 9000


a = Bar()
print(a.x)
reveal_type(a.x)  # revealed as int