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

[Stefan Krah]

Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:
> My issue is that until now sliced memoryviews are independent objects
> and are not affected by the releasing of the original memoryview. With
> this patch, they are, and that's why I'm advocating for a subtler
> approach (which would really mirror the current slicing semantics, and
> wouldn't break compatibility ;)).

I wrote a comment on rietveld (which failed to get mailed again). My plan
is to make the sliced views more independent by copying shape, strides,
and suboffsets unconditionally on construction.

Then it should always be possible to delete views independently.

With respect to releasing, the views are of course still dependent.

> release() is supposed to mean "you can dispose of this memoryview", not
> "you can dispose of any underlying memory area, even if there's some
> sharing that I as an user don't know anything about" (*). By making
> release() affect "related" memoryviews we are exposing an internal
> implementation detail (the PyManagedBuffer sharing) as part of the API.

I thought the rationale for the release() method was to allow sequences like:

b = bytearray()
m1 = memoryview(b)
m1.release() -> must call releasebuffer instantly.
b.resize(10) -> this might fail otherwise if the garbage collection is too slow.

So I think releasebuffer must be called on the original base object,
and only the ManagedBuffer can do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________