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

François Pinard pinard at iro.umontreal.ca
Wed Jan 21 20:24:57 EST 2004


[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



More information about the Python-Dev mailing list