Documentation bugs in 3.1 - C-API - TypeObjects
joost at h-labahn.de
Sun Nov 15 07:25:38 CET 2009
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.
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