> Is there a way to keep things (almost) as simple as this using the
> 'Capsules' ??
Most certainly. Instead of PyCObject_FromVoidPtr, use PyCapsule_New.
Either pass NULL as a name, or the class name for additional
type-safety. Instead of PyCObject_AsVoidPtr, use PyCapsule_GetPointer.
The only difference will be a change to the destructor function:
it gets the capsule now, rather than the embedded pointer.
> I do understand the advantage of having such a mechanism,
> but in this case it's sort of overkill...
It's the very same mechanism. The only difference is that capsules
are type-safe where CObjects were not. I.e. you can crash the
interpreter by passing in a bad CObject (one for a different type);
with capsules, this can be detected and a Python exception be raised.
Because of the additional type-safety, additional parameters are
needed, and because of that, a new name is needed. Nothing else
has changed.
In fact, you can do:
#if Python-version >= 3.2 (proper test left to the reader)
#define PyCObject_FromVoidPtr(C, ignored_destroy)
PyCapsule_New(C, "mymod.Class_XX", destroy_32)
#define PyCObject_AsVoidPtr(P) PyCapsule_GetPointer(P, "mymod.Class_XX")
extern "C" void destroy_32(PyObject *P){
destroy(PyCapsule_GetPointer(P, "mymod.Class_XX"));
}
#endif
This wouldn't do proper type-checking yet - all callers
of PyCObject_AsVoidPtr then should add
if (C == NULL) return NULL;
which still should be backwards-compatible with 3.1 and earlier
(in which versions you actually also should check for NULL, since
even PyCObject_AsVoidPointer can fail, esp. if you are passing
something that isn't a PyCObject).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
