[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

[Antoine Pitrou]

Antoine Pitrou <pitrou at 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 <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________