Documentation bugs in 3.1 - C-API - TypeObjects

DreiJane joost at
Sun Nov 15 07:25:38 CET 2009

Thanks !

Okay, i've already used the call of tp_free as the last
statement in tp_dealloc and do understand now, that a
call of tp_dealloc should be the last statement in the
code for tp_free in specific cases.

And yes, "Py_Type(&Foo_Type) = &PyType_Type" will be
more stable against changes of the object implementation.
Still there remains the difference to what is told with the
Noddy_Type in the tutorial.

Skimmimg through PyType_Ready in typeobject.c i find,

3760     if (Py_TYPE(type) == NULL && base != NULL)
3761              Py_TYPE(type) = Py_TYPE(base);

are the only lines referring to what is ob_type now. Thus
the quoted lines from the tutorial ending with "Fortunately,
this member will be filled in for us by PyType_Ready()."
are possibly wrong (respective outdated) too.

The two lines above are, what happens to my extension
classes, if i want to derive application classes from them.

class(my_extension_class): ...

will of course call more from Python than PyTypeReady,
but PyType(type) = Py_TYPE(base) is not getting corrected
by this "more" here and the class statement doesn't create
a new type. I will examine now, why this happens (without
a crash of the calling application !), but still welcome every
hint.  Seen from a strict perspective this is a bug in Python's
C-API. I'll save a freeze of the code for my extension for
anyone, who might interested to reproduce this.


More information about the Python-list mailing list