
[Raymond Hettinger]
Hmm, that surprises me. After all, writing class C(object): pass makes it new-style.
This is only because there is not __metaclass__ assignment within the class. In this case, according to: http://www.python.org/2.2.3/descrintro.html in the `Metaclasses' section, under "How is M determined?", we read: "... if there is at least one base class, its metaclass is used". The type of object is type itself. If there is no base class, then "if there's a global variable named __metaclass__, it is used." So my guess would be that adding a mere __metaclass__ = type in global scope for a module would make all classes be "new-style", without the need to subclass them from object explicitly. Experimenting a bit with these things, I noticed that `object.__new__' may be called from a class `__new__', and `object.__init__' the same, without that class needing to be subclassed from object. This does not help me getting away from the feeling that new-style classes do not need to be sub-classed from object. Another point is that in Python 3.0, it is unlikely that Guido forces everybody to subclass all classes from object, for these classes to work. I would not think that being sub-classed from object, at least explicitely in the class declaration, is a proper characterisation of new-style classes. This is one way of course, but not the necessary one. I was reading the "How-to ... Descriptors" as asserting this.
While true, I think it more pragmatic to have the docs and terminology *not* expressed in terms of meta-classes;
While docs and terminology need to be pragmatic, it is important that they could be dependable. One thing I would like to do is experimenting a lot of already written Python code in the context of new-style classes, just to see how solid things would be in that context. I suspect nothing will break, but we have to experiment it. My guess is that merely adding: __metaclass__ = type at the beginning of each module is sufficient for the experiment. It is simpler adding one line per module than to edit all base class declarations for adding (object) to them. I am not tempted to add them without at least understanding that they are really necessary. Adding at random would be symptomatic of my lack of grasp on the implied matters. In one other message, you assert that "All bets are off!" if I do not sub-class from object, but are you really damn fully sure of this? :-) It looks a bit like an argument of authority, and maybe more a guess than knowledge (no offence intended, of course). I just want to make sure I really got a definitive reply on this, and preferably, one that I can understand enough to repeat it myself with conviction! :-)
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)."
Yes, as long as this wording does not mislead the reader into thinking untrue things. Now, I'm not sure what `derive' really means. I read it as meaning `derive by explicit sub-classing', but it might imply something else. Without a precise meaning, the sentence is not so meaningful. The classic metatype itself is an object, you know, so one could say that classic classes also derive from object.
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.
Unless there is only two groups, in which case "lumping" would just get nearer the truth. I surely have to study a lot more, descriptors in particular, before I can make more sense of all this. Once again, I apologise for any wrong assertion I could have made above, or elsewhere, I do not intend to hurt or contradict anybody, but only to develop a more solid understanding. -- François Pinard http://www.iro.umontreal.ca/~pinard