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

[Greg Ewing]

Antoine Pitrou wrote:

> 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

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