[Python-Dev] Allocation of shape and strides fields in Py_buffer (original) (raw)

Antoine Pitrou solipsis at pitrou.net
Wed Dec 10 01:21:54 CET 2008

Greg Ewing <greg.ewing canterbury.ac.nz> writes:

1) The memoryview should not be holding onto a Pybuffer 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" Pybuffer 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.

More information about the Python-Dev mailing list