On Oct 1, 2019, at 12:17, 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 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. _______________________________________________ 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/4ZZQRTCYXFRFOMQI4S6ZBUWW47YHHKJM/ Code of Conduct: http://python.org/psf/codeofconduct/
