[Python-Dev] An updated extended buffer PEP

[Greg Ewing]

Carl Banks wrote:

> Now object B takes a view of A.  If we don't have this field, then B 
> will have to hold a reference to A, like this:
> 
> B -> A -> R
> 
> A would be responsible for keeping track of views,

A isn't keeping track of views, it's keeping track of the
single object R, which it has to keep a reference to anyway.

> and A could not be 
> garbage collected until B disappears.

I'm not convinced that this would be a serious problem. An
object that's using a different object to manage the buffer
is probably quite small, so it doesn't matter much if it
stays around.

> Here's a concrete example of where it would be useful: consider a 
> ByteBufferSlice object.  Basically, the object represents a 
> shared-memory slice of a 1-D array of bytes (for example, Python 3000 
> bytes object, or an mmap object).

And this would be a very small object, not worth the trouble
of caring whether it stays around a bit longer than needed,
IMO.

> P.S. In thinking about this, it occurred to me that there should be a 
> way to lock the buffer without requesting details.

Perhaps you could do this by calling getbuffer with NULL
for the bufferinfo pointer, and similarly call releasebuffer
with NULL to unlock it.

--
Greg