On Jun 17, 2009, at 10:08 AM, Dag Sverre Seljebotn wrote: > Dag Sverre Seljebotn wrote: >> Dag Sverre Seljebotn wrote: >>> Robert Bradshaw wrote: >>>> On a related note, it's still a bit unclear how these things can be >>>> passed around and stored. Are they just a Py_buffer + PyObject*? >>>> (I'm >>>> hoping you're thinking they can be passed around and stored with >>>> ease, with allocation either take care of by the corresponding >>>> object >>>> (which will clean up the memory when it gets collected) or if there >>>> is no object attached, the user needs to treat it as they would >>>> a raw >>>> pointer). >> >> To really answer this, yes. Reference counting etc., it will just >> work >> like any other Python reference from the user's perspective, with the >> usual caveats of "<object>char_ptr". >> > > Hmm. <object>char_ptr takes a copy I suppose though? So it's kind of > different, but at any rate deallocating C storage before a wrapping > array reference is destroyed is fatal. We could support > > a = int[:,:](some_c_ptr, deallocator=stdlib.free) > > though to transfer ownership.
This is starting to get messy, but I suppose not more so than http:// docs.python.org/c-api/cobject.html I would also be OK with a = <int[:50,:50]>some_c_ptr Where the corresponding object is None (or NULL) and no automatic deallocation occurs when a is reclaimed. Another option is to accept PyCObject as well as buffer-supporting objects if the dimensions are given. These details could he hashed out later, the important point is that they would be passed around and stored as normal refcounted objects (and require the GIL, including for slicing). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
