
After thinking this through some more, I have to retract that. After all, even classic classes and their instances are derive from object:
class C: pass
isinstance(C, object) True
isinstance(C(), object) True
Hmm, that surprises me. After all, writing class C(object): pass makes it new-style. Also dir(C()) or dir(C) does not show any of the methods given by dir(object) or dir(object()).
dir() special-cases classic classes. Classic class-ness and classic instance-ness are really subsumed by the new-style machinery -- there's a specific metaclass that produces classic classes, and those produce classic instances.
What makes a classic class is one very specific metaclass. What makes a classic instance is a class using that very specific metaclass. Everything else is a new-style class.
While true, I think it more pragmatic to have the docs and terminology *not* expressed in terms of meta-classes; rather, it is simpler to focus on the distinction between class C and class C(object), noting that all the new gizmos only work with the latter.
That's fine; there's nothing wrong with simply stating that classic classes don't *derive* from object. Note that in my little session I showed isinstance(C, object), which is True, but I didn't show issubclass(C, object), which is False -- it is the latter that makes C not a new-style class! (Not necessarily a classic class; it could be be an old-style extension type.)
The theory is simple, one shouldn't have to understand meta-classes in order be able to use property, classmethod, staticmethod, super, __slots__, __getattribute__, descriptors, etc.
Mostly right. But the fact that a class is also an object makes in unavoidable that the question is asked, and then you better have a good answer prepared.
Practically, in all code that doesn't explicitly create meta-classes, the sole trigger between new and old is adding object, list, or other builtin type as a base class.
Right. Or playing with __metaclass__, which is rare.
IOW, I think the docs ought to continue using wording like this for property: "Return a property attribute for new-style classes (classes that derive from object)."
I never said that was wrong. In fact IMO it is right.
There would be much loss of clarity and understanding with wording like: "Return a property attribute for a class whose metaclass is type or that implements the class semantics of type.__getattribute__ and the instance semantics of object.__getattribute__."
Of course.
For purposes of my article on descriptors, I'll continue with the current approach of ignoring meta-classes. There is enough information presented that meta-class writers will quickly understand why all the new-style gizmos stopped working when they didn't carry forward the semantics of object.__getattribute__ and type.__getattribute__.
Right. And meta-classes are still head-exploding material.
I think all of the topics are best understood in terms of three groups: classic classes, new-style classes, and roll your own classes. Lumping the latter two together won't help one bit.
Especially since it can be done using either classic or new-style classes. --Guido van Rossum (home page: http://www.python.org/~guido/)