Kristján Valur Jónsson <krist...@ccpgames.com> added the comment: Ah, the SHADOW member... Weird. Anyway, I have been hacking around in the memory view. One thing that it does, and makes me uncomfortable since I think it is breaking the new buffer protocol, is to a) PyObject_GetBuffer() b) Modify the resulting local Py_buffer c) releaseing that modified Py_buffer when it calls PyBuffer_Release()
I don't think one can do that, strictly speaking. You don't know what the buffer_releasebuffer() slot actually does, it might use the Py_buffer's "buf" member to release internal data, so I don't think it is permissable to mess with it. I was hacking away at the MemoryView to make it behave differently, perhaps more like the SHADOW buffer concept: When you call buffer_getbuffer on a memoryview, it returns a new Py_buffer that reflects its own view of the underlying object. In other words, it doesn't call PyObject_GetBuffer again on the underlying object A memoryview object should, IMHO, only perform that call once on the underlying object, and then serve its own view to its clients. Slicing memoryview objects should also be done differently. Rather than calling PyObject_GetBuffer() on the underlying object, it should rather refer to the origina MemoryView object, and create a local modification of that view. The only problem with this approact that I have found (having run the testsuite) is that the buffer_getbuffer slot now has to do more work, since it cannot simply call PyObject_GetBuffer() on some underlying object. It must now interpret flags and other things.... ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10293> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
