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

Greg Ewing greg.ewing at canterbury.ac.nz
Wed Dec 10 11:21:40 CET 2008

Antoine Pitrou wrote:

If the memoryview wasn't holding onto a Pybuffer, one couldn't rely on its length or anything else because the underlying object could be mutated at any moment

Hmm, it seems there are two different approaches that could be taken here to the design of a memoryview object.

You seem to be thinking of an "eager" approach where the memoryview keeps the underlying object's memory locked for as long as it exists, thus preventing it from being resized.

Whereas I've been thinking of it as being "lazy", in the sense that the memoryview simply remembers the slice parameters it was given, and waits until you access it before making any GetBuffer calls.

The lazy version would have the characteristic that creating a slice could succeed even though accessing it later fails due to a range error. I'm not sure that's necessarily a fatally bad thing.

I'm also not sure that the eager version would be totally immune to such things. The PEP seems to permit the shape to change while the buffer is locked as long as the overall size and location of the memory doesn't change, so a subsequent access to a formerly-valid slice could still fail.

In any case, I think it should be possible to implement either version without the memoryview having to own more than one Py_buffer and one set of shape/strides at a time. Slicing the memoryview creates another memoryview with its own Py_buffer and shape/strides.

-- Greg

More information about the Python-Dev mailing list