enforce Liskov Substitution Principle on subclasses

[carljm]

This means checking that subclass methods are subtypes of the superclass method they override, if any.

Subclass property getters must return a subtype of the corresponding superclass property getters, and subclass property setters must accept a supertype of the corresponding superclass property setter.

If we model any mutable attribute as conceptually a property with getter and setter, where the setter accepts the same type that the getter returns, this implies that the type of mutable attributes must be invariant; that is, subclasses may neither widen nor narrow the type of the attribute. Pyright models this correctly; mypy does not.

See #167 for a demonstration of a particular case involving ClassVar.

[jorenham]

Note that the LSP does not apply to Protocol that's marked as @final, because it's a purely structural, and cannot be used nominally. Both pyright and mypy model this incorrectly at the moment.

[carljm]

Note that the LSP does not apply to Protocol that's marked as @final

If I understand correctly, you are describing a case like this?

from typing import Protocol, final

class A(Protocol):
    x: int

@final
class B(A, Protocol):
    x: str

In this case it does seem intuitive to me to enforce Liskov between B and A (and thus error on B redefining x to str), because it ensures that the structural type B is assignable to the structural type A. This isn't necessary, but I think it matches the usual intuition for what inheritance means.

I'm also not sure why the @final on B actually matters here; I think the arguments for and against requiring B to match A are the same whether or not B is final?

[jorenham]

Note that the LSP does not apply to Protocol that's marked as @final

If I understand correctly, you are describing a case like this?

from typing import Protocol, final

class A(Protocol):
x: int

@Final
class B(A, Protocol):
x: str
In this case it does seem intuitive to me to enforce Liskov between B and A (and thus error on B redefining x to str), because it ensures that the structural type B is assignable to the structural type A. This isn't necessary, but I think it matches the usual intuition for what inheritance means.

I'm also not sure why the @final on B actually matters here; I think the arguments for and against requiring B to match A are the same whether or not B is final?

Hmm, this example shows that it isn't as easy as I initially thought, so I'll try to explain a bit better what I'm trying to say here.

One of the use-cases I had in mind, is this one

@final
class Unhashable(Protocol):
    __hash__: ClassVar[None]

If you'd enforce LSP here, then the __hash__ definition would be flagged as an LSP violation. But because this protocol 1) cannot be instantiated, and 2) cannot be subclassed, I was thinking that this LSP violation will never lead to type-safe unsafe situation.

But your example shows that these 2 conditions are not sufficient to guarantee type-safety in the absence of LSP — an additional condition is required.

---

So how about this:

The LSP does not apply to a method or attribute of a final Protocol when it directly overrides a member of object, and only of object.

Another way to think about it, is that final protocols behave as if they don't have object as a base class.

---

To illustrate, let's squash our examples, and apply the updated conditions:

class A(Protocol):
    x: int

@final
class UnhashableAndHasX(A, Protocol):
    __hash__: ClassVar[None]  # LSP doesn't apply => accept
    x: str                    # LSP applies       => reject

Does that make sense?

[carljm]

In principle, every Python object is an instance of object, and the API surface ofobject must be true for every Python object.

Thus, in principle, a protocol that isn't Liskov compatible with object is useless and describes a type that has no inhabitants (equivalent to Never).

However, as we know, for pragmatic/historical reasons, unfortunately the description of object in typeshed claims some things to be true which are not actually true for all Python objects, and causes Liskov violations in some situations.

But IMO this means that this is not an issue related specifically to Protocol or structural typing (because, for the accurate parts of the typeshed object definition, there is no value in, or need for, any special case for structural types). Thus I wouldn't support a general rule about Protocols and Liskov compatibility with object, because if we assumed a fully accurate typeshed object, that would be a useless / nonsensical rule.

Rather, this is an issue of how we handle Liskov for a few particular attributes of object (like __hash__) that are described wrongly in typeshed. I think the problem is specific to those problem attributes, but is not specific to Protocol; it is just as much a problem for non-Protocol inheritance as for Protocol inheritance.