[capi-sig] Obstacles for subclassing extension types - need hints

[Joost]

Hello,

these days i make depikt, a new minimalistic
gtk-interface, published on sourceforge.net.
For Python3, what all here is referring to.

First there were abstract classes for Container
and so on - they have been replaced by method
bundles added by the preprocessor to the individual
derived widgets, which of course are extension
classes.

Using one baseclass for gobjects, called Pikt.

I knew, this would not be simple, but what i hadn't
any idea of are the problems Python causes here.
 From cStringIO i knew, that there were some not
subclassable Python types, but i took that for
an exotic exception. I also had no idea, that
dynamic attributes are no standard behavior
(having never tried [1,2,3].a = "new attribute"
at a python prompt).

I've got dynamic attributes now, and inheritance
from the lower level classes in pango and gdk. But
inheritance for gtk.Window or gtk.VBox is much more
important in practice and after about 3 days of
trying (with TPFLAGS_HEAPTYPE for example) and
reading in object.c, objectimpl.c or typeobject.c
depikt's widget classes are still "idempotent":

class myEntry(depikt.Entry):  ...

doesn't crash but its __init__ creates - perfectly
usable - objects of the type depikt.Entry (what can
be iterated). A funny behavior, but seen from a strict
perspective a bug in the C-API (should crash. Or
are all such classes "idempotent" and is this needed
internally ?)

This here is from the preprocessor factory for the
widget types (initialized for Button for readability)
and from here the problem might stem:

378 PyObject *Button_new(PyTypeObject *type,
			PyObject *args,
			PyObject *kwds) {\
379	Button *self;\
380	self = (Button *)Pikt_new(&Button_Type, args, kwds); \
381	self->Q.gobj = PyCapsule_New(newfunc, "Button", NULL); \
382	if (! self->Q.gobj)
		{ Py_DECREF(self); KTERR("Cannot create Button");};\
383	return (PyObject *)self;\

That means, from line 380 (which follows a recommendation
of the tutorial and is vital. It also took nearly a day to
find out, that Pikt_new can accept a Button_Type*, that is
not documented and far from obvious).

Could somebody give me a complete list of obstacles
for inheritance from the C-API ? Including the nexus
to allocation ? I do not mean explicit explanation of
each obstacle. Hints for each item are fully enough.

Thanks for reading, Joost