issubclass(dict, Mapping)

[kj]

In a message (<4cf97c94$0$30003$c3e8da3$5496439d at news.astraweb.com>)
on a different thread, Steven D'Aprano tells me:

>I suspect you're trying to make this more complicated than it actually 
>is. You keep finding little corner cases that expose implementation 
>details (such as the heap-types issue above) and leaping to the erroneous 
>conclusion that because you didn't understand this tiny little corner of 
>Python's class model, you didn't understand any of it. Python's object 
>model is relatively simple, but it does occasionally expose a few messy 
>corners.

I disagree with your assessment.  What you call "little corner
cases" I call "fundamental", as in "you can't really call yourself
competent with Python if you're ignorant about them".

To use a term I first saw in an article by Joel Spolsky
(http://is.gd/je42O), Python's object model is a rather "leaky
abstraction".  This refers to the situation in which a user is not
shielded from the "implementation details".  When an abstraction
leaks, implementation details are no longer negligible, they cease
to be "little corner cases".

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.

I suspect this is another abstraction leak ("dict is *supposed* to
be a Python class like all others, but in fact it's not *really*.
You see, once upon a time...").

I conclude that, for me to understand Python's (rather leaky) object
model abstraction, I have to understand its underlying implementation.
Unfortunately, as far as I know, there's no other choice but to
study the source code, since there's no other more readable
description of this implementation.

Maybe there are fewer "abstraction leaks" in 3.0... 

~kj