[Python-Dev] Allocation of shape and strides fields in Py_buffer

[Travis Oliphant]

Alexander Belopolsky wrote:
> On Mon, Dec 8, 2008 at 6:25 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> ..
>>> Alexander's suggestion of going and looking at what the numpy folks have
>>> done in this area is probably a good idea too.
>> Well, I'm open to others doing this, but I won't do it myself. My interest is in
>> fixing the most glaring bugs of the buffer API and memoryview object. The numpy
>> folks are welcome to voice their opinions and give advice on python-dev.
>>
> 
> I did not follow numpy development for the last year or more, so I
> won't qualify as "the numpy folks," but my understanding is that numpy
> does exactly what Nick recommended: the viewed object owns shape and
> strides just as it owns the data.  The viewing object increases the
> reference count of the viewed object and thus assures that data, shape
> and strides don't go away prematurely.
> 
> I am copying Travis, the author of the PEP 3118, hoping that he would
> step in on behalf of "the numpy folks."

I appreciate the copy, as I mentioned I have not had time to follow 
python-dev in detail this year, but I'm glad to help maintain the buffer 
protocol and share any information I can.

I think Nick understands the situation:  the exporter is responsible for 
  allocating and freeing shape, strides, and suboffsets memory (as well 
as  formats, and buf memory).   How it does this is not specified and 
open for interpretation by the objects.  In the standard library there 
is nothing that needs anything complicated and I'm comfortable with what 
I wrote previously to support the objects in the standard library.

There is a length bug in the memoryview implementation, but that is a 
separate issue and being handled.

NumPy will have to handle sharing shape and strides information and will 
serve as a reference implementation when that support is added.

-Travis