This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients jcon, kermode, mark.dickinson, ncoghlan, petri.lehtinen, pitrou, pv, rupole, skrah, teoliphant, vstinner
Date 2011-07-06.13:16:43
SpamBayes Score 4.440892e-15
Marked as misclassified No
Message-id <1309958204.04.0.646143482692.issue10181@psf.upfronthosting.co.za>
In-reply-to
Content
Yeah, the reason my originally proposed semantics were wrong is because copying (or slicing) a memoryview object and then explicitly releasing that object would always fail through no fault of that code. That would be broken and the only way to fix it is to allow the release() call but not actually call the ReleaseBuffer API until all the buffer references are gone.

Exports are different - whenever you copy or slice a memoryview, you get a new memoryview object with the export count set to zero, so it is reasonable to require that anyone that wants to explicitly release the memoryview's buffer reference make sure that there aren't any exports hanging around. Keep in mind that memoryview copies and slices don't increase the export count, as those will refer directly back to the original managed buffer.

+1 on tracking buffer exports explicitly rather than relying solely on playing games with refcounts though - while technically redundant in the ManagedBuffer case, I agree it will make the code far more self-explanatory.
History
Date User Action Args
2011-07-06 13:16:44ncoghlansetrecipients: + ncoghlan, teoliphant, mark.dickinson, rupole, kermode, pitrou, vstinner, pv, skrah, jcon, petri.lehtinen
2011-07-06 13:16:44ncoghlansetmessageid: <1309958204.04.0.646143482692.issue10181@psf.upfronthosting.co.za>
2011-07-06 13:16:43ncoghlanlinkissue10181 messages
2011-07-06 13:16:43ncoghlancreate