Antoine Pitrou <pit...@free.fr> added the comment: > Problems remain. Suppose `bf_getbuffer` for memoryview is implemented > so that it returns a view exported by the original object (and not the > memoryview). Consider an example: > > >>> obj = PictureSet() # exposes a buffer, say, to "pic_1" > >>> a = memoryview(obj) # points to pic_1 > > Here, `a` grabs a lock to pic_1. > > >>> obj.choose_picture(2) # switches the exposed buffer to > pic_2
That's a very bad API to begin with. Anyone thinking it is reasonable to have the concept of a "current element" in a container should write PHP code instead. If you have individual pictures, please use individual objects. > >>> b = memoryview(obj) # points to pic_2 > >>> c = memoryview(a) > > Here, PyObject_GetBuffer in bf_getbuffer for `a` grabs a lock to pic_2 > and passes it on to `c` So what? c will represent pic_2 anyway, so the behaviour is right. Awful certainly for the user, but that's because PictureSet implements a braindead API. > , and the buffer may be freed (also, if the handling of shape/stride > arrays in memoryview is as it is now, also those are invalidated). One > of the two is now true: `memoryview(a)` does not always describe the > same area of memory as `a`, OR, `c` ends up with a lock on the wrong > area of memory and the program hits a SEGV. This all points to completely broken logic in the imaginary PictureSet class. If someone doesn't get their semantics right, it is not the buffer API's problem. bf_getbuffer and bf_releasebuffer must implement symmetric operations; perhaps that's not explicitly worded, but it seems quite obvious to me. > The alternative would be to adjust the spec so that the above type of > behavior is forbidden (any buffers and the shape/stride arrays ever > exported must remain valid until the last one is released). Why would you adjust the spec? This just stems from common sense. If you provide a pointer to a consuming API, you have to ensure the pointer remains valid as long as the consuming API is using that pointer. Actually, that's *exactly* why there's a bf_releasebuffer method at all. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10181> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
