[Python-Dev] RE: Hot-To Guide for Descriptors - Nits! :-)
Guido van Rossum
guido at python.org
Wed Jan 21 17:03:15 EST 2004
> > 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__."
> 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__.
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
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev