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