The major difference between all these examples and ctypes is that
ctypes has no way of introspecting the wrapped library; you have to
repeat everything you know about the API in your calls to ctypes (and
as was just shown in another thread about 64-bit issues, that's not
always easy).
An excellent point and very clarifying (though I still don't totally understand the relationship with Parrot).
What do you think about techniques like these:
* http://starship.python.net/crew/theller/ctypes/old/codegen.html
* http://lists.copyleft.no/pipermail/pyrex/2006-June/001885.html
I agree that this is an issue.
But then on the other hand, given N methods and objects that you need wrapped, you will in general need to make N individual mapping statements no matter what technology you use. The question is how many lines of mapping are you doing? Ctypes currently requires you to re-declare what you know about the C library. Hand-written C libraries require you to do go through other hoops.
For example, looking at Pygame ctypes, consider the following method:
def __copy__(self):
return Rect(self.x, self.y, self.w, self.h)
That's the ctypes version. Here's the C version:
/* for copy module */
static PyObject* rect_copy(PyObject* oself, PyObject* args)
{
PyRectObject* self = (PyRectObject*)oself;
return PyRect_New4(self->r.x, self->r.y, self->r.w, self-> r.h);
}
static struct PyMethodDef rect_methods[] =
{
... {"__copy__", (PyCFunction)rect_copy, 0, NULL},...
};
So there is some repetition there as well (casts, function name duplications, etc.).
Paul Prescod
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
