[capi-sig] PyObject_Type with no tp_new - any dangers ?
Joost
joost at h-labahn.de
Sat Nov 7 22:21:55 CET 2009
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
More information about the capi-sig
mailing list