[Python-Dev] RE: Hot-To Guide for Descriptors - Nits! :-)

[Guido van Rossum]

> > 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/)