On Wed, Oct 2, 2019 at 5:18 AM Ben Rudiak-Gould <benrudiak@gmail.com> wrote:
On Tue, Oct 1, 2019 at 9:26 AM Andrew Barnert <abarnert@yahoo.com> wrote:
On Sep 30, 2019, at 23:46, Ben Rudiak-Gould <benrudiak@gmail.com> wrote:
ABC membership is a subtype relationship in some sense, and ordinary Python subclassing is a subtype relationship in some sense, but they aren't quite the same sense,
But in this case, they actually match. Hashable is correctly checking for structural subtyping, and the problem is that list isn’t actually a proper subtype of object, not that object isn’t a proper subtype of Hashable.
If you take the perspective that the ABC notion of subtyping is the correct one, then list isn't a proper subtype of object. I wasn't taking the perspective that either one is the correct one. I think they're probably both okay in isolation.
If you want to get REALLY technical, very few types - if any - are actually proper subtypes. A strict reading of the Liskov Substitution Principle would imply that the repr of every object should remain identical to object.__repr__ of that object. That's completely useless, of course, but the question is: if a subclass is allowed to make changes to its parent's behaviour, where do you draw the line? For instance, it is extremely common to expect that x == x for any object x, but float is a subtype of object, and not every float maintains that property. The base object type compares by identity, so object() != object(). Is it violating LSP if two non-identical objects compare equal? The base object is immutable. Subtypes that are also immutable will follow the principle that if a == b now, then a == b forever. Is it violating LSP to have mutable objects that can compare equal now but unequal later? The hashability issue is a logical consequence of accepting that the above violations are reasonable and practically useful. Since a==b must imply that hash(a)==hash(b), it logically follows that either the hash of every list is the same (thus destroying the value of hashing at all), or the hash of a list could change (thus destroying the very meaning of object hashes). I'm not sure what would break if every list object had a hash of 0x142857, but certainly it wouldn't be of much practical use, and would be a performance nightmare (you use a list as a dict key and suddenly every lookup is a linear search). Yes, it's not a "proper subtype", but proper subtypes are impractically restrictive. ChrisA