> > 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4