On Thu, 23 Dec 2010 01:41:08 +0000, kj wrote:
> In <4d127d5e$0$29997$c3e8da3$54964...@news.astraweb.com> Steven D'Aprano
> <steve+comp.lang.pyt...@pearwood.info> writes:
>
>>On Wed, 22 Dec 2010 14:20:51 +0000, kj wrote:
>
>>> Here's another example, fresh from today's crop of wonders:
>>>
>>> (v. 2.7.0)
>>>>>> from collections import Mapping
>>>>>> issubclass(dict, Mapping)
>>> True
>>>>>> dict.__bases__
>>> (<type 'object'>,)
>>>>>> [issubclass(b, Mapping) for b in dict.__bases__]
>>> [False]
>>>
>>> So dict is a subclass of Mapping, even though none of the bases of
>>> dict is either Mapping or a subclass of Mapping. Great.
>
>
>>Yes. So what?
>
> That's being deliberately obtuse. The situation described goes smack
> against standard OOP semantics,
What are these "standard OOP semantics" you're referring to, and who made
them "standard"? If people can't even decide whether multiple inheritance
should be allowed or not, what makes you think that there is any such
thing as "standard OOP"?
I think you are confusing concrete implementation details with the
interface. The interface for subclass testing in Python is as follows:
A class K is a subclass of class C if, and only if,
issubclass(C, K) returns a true result.
That's it. Everything else is implementation. __bases__ is
implementation. __subclasscheck__ is implementation. If Python adds a
third mechanism for implementing subclass checks in version 3.3 or 3.4,
the interface will just continue to work correctly.
> which would be fine if all this stuff
> was documented clearly and reasonably, i.e. in one (preferably
> "official") place rather than scattered over a bazillion separate
> documents, PEP this, module that, GvR musing #42, etc.
This is documented, in the docs.
http://docs.python.org/reference/datamodel.html#customizing-instance-and-subclass-checks
Nobody says the Python docs are perfect, but most things you ask are in
there. Patches for the docs to improve them are welcome.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
