On Oct 1, 2019, at 12:17, 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 don’t think anyone takes that perspective. The correct notion of subtyping for Python is the one that exactly reproduces duck typing in an LBYL-checkable way, which I’ll bet is provably equivalent to the halting problem. However, the whole mess of things that go into isinstance and issubclass in Python (including third-party code) together define a pretty-good-in-practice approximation of that, when user with most real-life code. And a much better one than either inheritance or structural tests alone.
My problem is not that I can't justify the current behavior, it's that if it behaved differently, I could justify that behavior too. I feel like you're using CPython as an oracle of what ABCs should do,
Well, I’m using all Python implementations, together with all of the popular third-party code out there, as used by thousands of people every day, allowing us to work with types in a way that’s more pleasant to read than Java or Go or Objective C or Ruby, as an argument that Python’s design is in practice pretty good. I can make a good argument that inheritance alone, or structural subtyping alone, would be so terrible as to be nearly useless for Python. I can’t make an argument that no possible thing you could think of could be better than what Python currently does. (In fact, I can think of things I’d suggest be done differently if I had a time machine back. Then again, I could improve even more things with even less work by taking that time machine even further back and giving Guido the 2.3 type system back in 0.9, or *args and **kw.) But I don’t see why I have to make an argument for a years-old feature just because someone wants to add a minor extension that goes along with the way that feature has always been used. If you hate ABCs, you’re not going to use collections.abc.Subscriptable now matter how it’s bikeshedded.
What *should* it mean to inherit from an ABC? The module encourages you to use them as mixins, but maybe that isn't the intended meaning, just a side hack? Is the primary meaning to do the equivalent of registering the class with the predicate?
The intended meaning clearly is a mix of multiple things: some of them do structural subtyping, some don’t; some rely heavily on registration; some act as useful mixins, some don’t; etc. Theoretically, abc is a bit of a mess, and collections.abc, numbers, and io are a horrible pile of unusable crap. But in practice, they actually work pretty nicely in a wide range of code that people read every day.