Author skrah
Recipients jcon, kermode, mark.dickinson, ncoghlan, petri.lehtinen, pitrou, pv, rupole, skrah, teoliphant
Date 2011-06-27.17:17:06
SpamBayes Score 2.63496e-07
Marked as misclassified No
Message-id <20110627171506.GA26001@sleipnir.bytereef.org>
In-reply-to <1309180676.88.0.541176207355.issue10181@psf.upfronthosting.co.za>
Content
Nick Coghlan <report@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.
History
Date User Action Args
2011-06-27 17:17:08skrahsetrecipients: + skrah, teoliphant, mark.dickinson, ncoghlan, rupole, kermode, pitrou, pv, jcon, petri.lehtinen
2011-06-27 17:17:07skrahlinkissue10181 messages
2011-06-27 17:17:06skrahcreate