Hello,
these days i made depikt, a new minimalistic gtk-interface, published on sourceforge.net.
depikt realizes the abstract base classes of gtk like GObject, Widget or Container as extension classes defining no tp_new and is using this preprocessor template for it:
#define DEPIKT_ABSTRACT_PYOB_HEADER(XXX)
typedef struct {
PyObject_HEAD
Gtk##XXX *gwidget;
} XXX;
static PyTypeObject XXX##_Type;
#define DEPIKT_ABSTRACT_PY_TYPE(x)
static PyTypeObject XXX##_Type = {
PyObject_HEAD_INIT(NULL)
0,
"depiktmodule."#XXX,
sizeof(XXX),
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
PyObject_GenericGetAttr,
PyObject_GenericSetAttr,
0,
Py_TPFLAGS_DEFAULT|Py_TPFLAGS_BASETYPE,
"Python type object for "#XXX,
0, 0, 0, 0, 0, 0,
XXX##_methods
};
and that is nearly all depikt does for these types (except the eventual tp_base-supplement in the PyMODINIT_FUNC), no tp_new, no tp_dealloc - but a canonical method table with the needed methods is added of course.
Inheritance works, because for example a GtkContainer* is also a GtkWidget* - that is how gtk handles inheritance in C. Thus the Container_Type has a GtkWidget* in his core struct indeed.
So far this is working, gtk_container_set_focus_chain for example is doing well. However in classes inheriting from depikt.Window there is bad behavior in the second generation.
(It is not the first Python extension i write, but the first more ambitious, and also the first more ambitious C project. Thus i am glad to have come so far (basically depikt works fine) - but with the complex type system of gtk and my inexperience with Python extensions i need help at this point. I am looking for a decent co-author.)
Here my question: Are their problems with abstract classes like this in Python ? I supposed not - otherwise i had not continued with the development of depikt to this point -, but i want to exclude error sources. Can i do anything to "harden" the concept ?
Thanks for reading, Joost