Stefan Krah <stefan-use...@bytereef.org> added the comment: Nick Coghlan <rep...@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 <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
