Virtual subclassing is key to the way ABCs work. It would be nice if it were explained better in the docs, but I suppose usually people don’t need to know the details unless they’re actually getting involved in something like designing new ABCs, so…
Thanks for the concise explanation. I guess my objection was not about the ABC (or how it works), but about the single fact that the function `issubclass` gives the results which are counter intuitive. Yes, we know, that those three calls:
>>> issubclass(list, object)
are correct, i.e. there is nothing wrong with each one individually. It is just that all together are contradicting. And it is not because of the objects (how they are), but because what the function does, and in particular that it does two different things (but pretends it is one). If `issubclass` tested the inheritance, and there was a function `collections.abc.islikeabc` doing the other thing, I would not say a word.
The problem, as I perceive it, is not in a fact that a class can mangle its dunder methods in a way it becomes "contradicting" itself, as in, for example, deriving from object and then disabling __hash__, or deriving from list and removing __getitem__, but in the fact that someone decided to merge two different and basically independent functionalities into one function.
And these functionalities are different, because they answer two different questions. First is about the class origin (heritage), the other is about the class behavior (interface), where neither one implicate necessarily the other, but I digress.
For what concerns "issubscriptable" my only comment is that so far it does not seem there is a consensus about what exactly "subscriptable" means (or should mean) and the regular user (like myself) could probably be even more confused (like I am about `issubclass` right now).