Antoine Pitrou <pit...@free.fr> added the comment: Hello,
> I spent today some time to rewrite `memoryobject.c`, and cleaning up > the Py_buffer handling in it. (I wrote also the Numpy PEP 3118 > implementation, so this was straightforward to do.) Thanks for trying this. > - Rewritten memoryobject: > > http://bitbucket.org/pv/cpython-stuff/src/817edc63ce4d/Objects/memoryobject.c Some worrying things here: * memoryview_getbuffer() doesn't call the original object's getbuffer. This means that if I do: m = memoryview(some_object) n = memoryview(m) m.release() n ends up holding a buffer to some_object's memory, but some_object doesn't know about it and can free the pointer at any time. * same for _get_sub_buffer_index() and _get_sub_buffer_slice0(). Actually, the whole concept of non-owner memoryviews seems flawed. * the fact that slicing increments the parent memoryview's refcount means that a loop like: while len(m): # do something m = m[1:] will end up keeping N chained memoryviews on the heap. Currently only the last memoryview remains alive. Some other things: * why do you accept the ellipsis when indexing? what is it supposed to mean? * please don't use #warning. Just put the TODO in a /* ... */. * please no "#if PY_VERSION_HEX >= 0x03000000". Just make your source py3k-compatible and we'll take care of backporting it to 2.x if your patch is accepted ;) ---------- _______________________________________ 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
