kj wrote:
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".
So where on the sliding scale do you place 'competent'? It sounds to me
like you are looking at 'master'.
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]
Firstly, as I'm sure you know, if you don't import Mapping from
collections the issubclass test fails with a NameError.
Secondly, why do you care? Did you get bitten by something? Some
error, or worse, silently got wrong results? (Sincere question.)
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
My take on abstraction leaks is when the underlying actuality shows
through in a non-ignorable way -- so I ask again, how is this
discrepancy making it so you can't ignore it?
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
