tp_base, ob_type, and tp_bases
jeff at jmcneil.net
Sat Jan 17 17:09:30 CET 2009
On Jan 17, 10:50 am, "Martin v. Löwis" <mar... at v.loewis.de> wrote:
> > So, the documentation states that ob_type is a pointer to the type's
> > type, or metatype. Rather, this is a pointer to the new type's
> > metaclass?
> That's actually the same. *Every* ob_type field points to the object's
> type, e.g. for strings, integers, tuples, etc. That includes type
> objects, where ob_type points to the type's type, i.e. it's meta-type,
> also called metaclass (as "class" and "type" are really synonyms).
> > Next, we have tp_base. That's defined as "an optional pointer to a
> > base type from which type properties are inherited." The value of
> > tp_base is then added to the tp_bases tuple. This is confusing me. On
> > the surface, it sound as though they're one in the same?
> (I don't understand the English "one in the same" - interpreting it
> as "as though they should be the same")
> No: tp_bases is a tuple of all base types (remember, there is multiple
> inheritance); tp_base (if set) provides the first base type.
> > I *think* (and dir() of a subclass of type seems to back it up), that
> > tp_base is only at play when the object in question inherits from
> > type?
> No - it is the normal case for single inheritance. You can leave it
> NULL, which means you inherit from object.
Thank you! It was tp_base that was confusing me. The tp_bases member
makes sense as Python supports multiple inheritance. It wasn't
immediately clear that tp_base is there for single inheritance
reasons. It's all quite clear now.
Is that an optimization of sorts?
More information about the Python-list