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

[Stefan Krah]

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

Nick Coghlan <report at bugs.python.org> wrote:
[Snip liberally]
> The lifecycle problem is unrelated to the details of the buffer *contents*
  though - it's entirely about the fact that clients can't safely copy all
  those pointers (as some may refer to addresses inside the struct) and asking
  the original object for a fresh copy is permitted to return a different answer
  each time.

> The actual *slicing* code in memoryview isn't too bad

I promise that I'll keep quiet about the getslicedbufferproc from now on, since 
there isn't much enthusiasm. :)

The reason I kept mentioning it was that I thought it would eliminate the
need to copy anything at all. All buffers would come from a single, memory
owning base object.

> Does all that make my perspective any clearer?

Yes, thank you. The tricky part is to understand why always redirecting
getbuffer/releasebuffer to the underlying *original base object* is not
sufficient, but as I understood Pauli's last posting that is due to the
addition of the release() method.

----------

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