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, that 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. Joost -- http://mail.python.org/mailman/listinfo/python-list
