In a message (<4cf97c94$0$30003$c3e8da3$54964...@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 -- http://mail.python.org/mailman/listinfo/python-list
