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

Travis Oliphant oliphant.travis at ieee.org
Wed Dec 10 17:34:09 CET 2008


Nick Coghlan wrote:
> Antoine Pitrou wrote:
>> In all honesty, I admit I am annoyed by all the problems with the buffer API /
>> memoryview object, many of which are caused by its utterly bizarre design (and
>> the fact that the design team went missing in action after imposing such a
>> bizarre and complex design on us), and I'm reluctant to add yet another level of
>> byzantine complexity in order to solve those problems. It explains I may sound a
>> bit angry at times :-)
>>
>> If we really need to change things a lot to make them work, we should re-work
>> the buffer API from the ground up, make the Py_buffer struct a true PyObject
>> (that is, a true variable-length object so as to solve the shape and strides
>> allocation issue) and merge it with the current memoryview implementation. It
>> would make things both more simpler and more flexible.
> 
> I don't see anything wrong with the PEP 3118 protocol. It does exactly
> what it is designed to do: allow the number crunching crowd to share
> large datasets between different libraries without copying things around
> in memory. Yes, the protocol is complicated, but that is because it is
> trying to handle a complicated problem.
> 
> The memoryview implementation on the other hand is pretty broken. I do
> have a theory on how it ended up in such an unusable state, but I'm not
> particularly inclined to share it - this kind of thing can happen
> sometimes, and the important question now is how we fix it.
> 

Thank you Nick.   This is a correct assessment of the situation.  I'd 
like to help improve memoryview as I can.  It does need thought about 
what you want memoryview to be.

I wanted memoryview to be able to be sliced and diced (much like NumPy 
arrays).  But, I only was able to get around to implementing the (simple 
view of Py_buffer struct).


-Travis



More information about the Python-Dev mailing list