On Wed, Oct 2, 2019 at 5:18 AM Ben Rudiak-Gould <benrud...@gmail.com> wrote: > > On Tue, Oct 1, 2019 at 9:26 AM Andrew Barnert <abarn...@yahoo.com> wrote: > > On Sep 30, 2019, at 23:46, Ben Rudiak-Gould <benrud...@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 _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HHHKXLRQSYA7UAUQVFSZIPIYEANZHX32/ Code of Conduct: http://python.org/psf/codeofconduct/
