[Python-3000] Ctypes as cross-interpreter C calling interface

[Paul Prescod]

On 8/14/06, Guido van Rossum <guido at python.org> wrote:
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060814/a281094f/attachment.htm