[Cython] Cython array type: Summary, introducing CEP 518

[Robert Bradshaw]

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