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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
