PyCObject_FromVoidPtr etc.

Fons Adriaensen fons at linuxaudio.org
Tue Mar 22 19:03:47 EDT 2011


Hello all,

Upgrading to 3.2 has provided some sort of cold shower.

I have hundreds of extensions that fail to install due to
PyCObject_FromVoidPtr() and PyCObject_AsVoidPtr() not longer
being available, and I'm looking for a (hopefully) simple
solution.

In all cases, these are extensions that create an instance
of a C++ class which is purely a 'slave' to the corresponding
instance of a Python class.

They all follow a pattern illustrated by the following code:


-------
#include "class_XX.h"


extern "C" void destroy (void *object)
{
    Class_XX *C;

    C = (Class_XX *) object;
    delete P;
}


extern "C" PyObject* create (PyObject *self, PyObject *args)
{
    Class_XX *C;
    PyObject *P;
    int a, b;

    if (! PyArg_ParseTuple(args, "(Oii)", &P, &a, &b)) return NULL;
    C = new Class_XX (P, a, b);
    return PyCObject_FromVoidPtr((void *) C, destroy);
}


extern "C" PyObject* method_1 (PyObject *self, PyObject *args)
{
    Class_XX *J;
    PyObject *P;
    int x, y;

    if (! PyArg_ParseTuple(args, "(Oii)", &P, &x, &y)) return NULL;
    C = (Class_XX *) PyCObject_AsVoidPtr(P);
    P = Py_BuildValue ("(i)", C->method_1 (x, y));
    Py_INCREF (P);
    return P;
}

...

------


The C++ object stores a pointer to its Python equivalent (not needed
in most cases, only if there would be callbacks) and the Python object
stores a PyCObject corresponding to its C++ slave and uses this to call
its methods.

In no case there is any need of the C++ objects being visible anywhere
else, let alone in other extensions.

Is there a way to keep things (almost) as simple as this using the
'Capsules' ?? I do understand the advantage of having such a mechanism,
but in this case it's sort of overkill...

TIA,

-- 
FA









More information about the Python-list mailing list