[Python-Dev] Assertion in _PyManagedBuffer_FromObject()

[Stefan Behnel]

Stefan Krah, 02.03.2012 17:42:
> Stefan Krah wrote:
>>> Why would the object that bf_getbuffer() is being called on have to
>>> be identical with the one that exports the buffer?
>>
>> It doesn't have to be. This is now possible:
>>
>> >>> from _testbuffer import *
>> >>> exporter = b'123'
>> >>> nd = ndarray(exporter)
>> >>> m = memoryview(nd)
>> >>> nd.obj
>> b'123'
>> >>> m.obj
>> <ndarray object at 0x7fbef33677d8>
> 
> Stefan (Behnel), do you have an existing example object that does
> what you described? If I understand correctly, in the above example
> the ndarray would redirect the buffer request to 'exporter' and
> set m.obj to 'exporter'.

Yes, that's a suitable example. It would take the ndarray out of the loop -
after all, it has nothing to do with what the memoryview wants, and won't
need to do any cleanup for the memoryview's buffer view either. Keeping it
explicitly alive in the memoryview is just a waste of resources.

It's also related to this issue, which asks for an equivalent at the Python
level:

http://bugs.python.org/issue13797


> It would be nice to know if people are actually using this.

I'm not using this anywhere. My guess is that it would be more of a feature
than something to provide legacy code support for, but I can't speak for
anyone else. In general, the NumPy mailing list is a good place to ask
about these things.


> The reason why this scheme was not chosen for a chain of memoryviews
> was that 'exporter' (in theory) could implement a slideshow of buffers,
> which means that in the face of redirecting requests m might not be
> equal to nd.

Right. Then it's only safe when the intermediate provider knows what the
underlying buffer providers do. Not unlikely in an application setting,
though, and it could just be an option at creation time to activate the
delegation for the ndarray above.

Stefan