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

[Antoine Pitrou]

Greg Ewing <greg.ewing <at> canterbury.ac.nz> writes:
> 
>    1) The memoryview should *not* be holding onto a Py_buffer
>       in between calls to its getitem and setitem methods. It
>       should request one from the underlying object when needed
>       and release it again as soon as possible.

If the memoryview wasn't holding onto a Py_buffer, one couldn't rely on its
length or anything else because the underlying object could be mutated at any
moment (even by another thread). It would make memoryview objects basically
unusable for anything except bytes objects (which are immutable).

>    2) The "second" Py_buffer referred to above only needs to
>       be materialized when someone makes a GetBuffer request on
>       the memoryview itself.

It's already what is being done, but that's got nothing to do with the problem
at hand. We are talking about slicing the memoryview, not taking a (non-sliced)
buffer of it.

>       It's not needed for Python getitem
>       and setitem calls.

What is needed for Python getitem and setitem calls is proper shape information
in the embedded Py_buffer struct, otherwise memoryview slices are buggy. In the
case of a memoryview slice, the proper shape information can only be computed
*after* the Py_buffer is obtained.

> It sounds to me like whoever wrote the memoryview implementation
> didn't understand how the buffer interface is meant to be used.

Perhaps, perhaps not, but without any concrete suggestion we won't go anywhere.

As I said, I don't think it would be foolish to revamp the current spec and/or
implementation /if we have a precise plan of how to do better/. The /if/ part is
important :-)

Regards

Antoine.