Thomas Heller wrote:
From: "M.-A. Lemburg" firstname.lastname@example.org
[Metatypes, callbacks, etc.]
Wouldn't it be *much* easier to just use the copyreg/pickle API/protocol for dealing with all this ?
I *don't* think it's complicated (once you get used to metatypes).
I hear heads exploding already :-)
AFAICTL, the actions needed by Jack are very similar to what pickle et al. do, and we already have all that in Python -- it's just not exposed too well at C level.
PyArg_ParseTuple(args, "O@", &factory, &tuple) would return a factory function and a tuple storing the data of the object passed to the function
Py_BuildValue("O@", factory, tuple) would simply call factory with tuple and use the return value as object.
(Note that void* can be wrapped into PyCObjects for "use" in Python.)
I'm not sure we talk about the same thing: we (at least me) do not want to serialize and reconstruct objects (what pickle does), we want to convert objects from Python to C (convert them to parameters usable in C API-calls), and back (convert them from handles, pointers, whatever into Python objects) having only the Python *type* object available in the latter case.
Or am I missing something?
I'm not really talking about serializing in the pickle sense (with the intent of storing the data as string), it's more about providing a way to recreate an object within the same process: given an object x, provide a factory function f and a tuple args such that x == apply(f, args).
Now, the object Jack has in mind wrap C pointers, so the args would be a tuple containing one PyCObject. Getting the pointer out of a PyCObject is really easy and by using a tuple as intermediate storage form, you can also support more complex objects, e.g. objects wrapping more than one pointer or value.
After you have accessed the internal values, possibily calculating new ones, you can then contruct a tuple, pass it to the factory and return the same type of input object as you received no input.
Since the API would be fixed, helper functions could be added to make all this really easy at C level.
The fact that a registry similar to copyreg or a new method on the input object is used to contruct the factory function and the tuple, this mechanism can easily be extended in Python as well as C.
Furthermore, the existing pickle mechanisms could be reused for the existing objects, since most of these use very reasonable state tuples for storing the object state.
I'm just suggesting this to make the whole wrapper idea more flexible. One C void* pointer is really only useful for very simple objects. The above easily extends to complex objects such as e.g. mxDateTime objects.