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 mark.dickinson
Recipients kermode, loewis, mark.dickinson, ncoghlan, pitrou, rupole, teoliphant
Date 2011-01-05.13:51:09
SpamBayes Score 8.589296e-12
Marked as misclassified No
Message-id <1294235472.46.0.552919343366.issue10181@psf.upfronthosting.co.za>
In-reply-to
Content
Nick, it sounds as though you have an idea of how you think things should be working here---perhaps you can help me out.  I'd really like to understand what the implementation should look like from the POV of a 3rd party module that defines some object exporting the buffer interface.

Here's a specific scenario I'd like to understand:  module foo defines a type Foo that implements the buffer protocol.  For simplicity, suppose it's exporting 1-dim buffers. When I do:

>>> from foo import Foo
>>> foo_object = Foo()
>>> m = memoryview(foo_object)
>>> n = m[::2]  # take a slice of m
>>> del m       # delete the objects, in whichever order.
>>> del n

what's the sequence of getbuffer and releasebuffer calls that foo_object should expect to see?

Q1. Does foo get 2 requests to getbuffer (and 2 to releasebuffer), or just one each?  I'm assuming at least that getbuffer and releasebuffer calls should be paired.

Q2. For each pair of getbuffer/releasebuffer calls, should the 'view' parameter passed into releasebuffer be identical to that provided to getbuffer?  Or is it acceptable for the actual Py_buffer* pointers to be distinct, but the pointed-to Py_buffers to be exact copies.  (The existence of the smalltable field complicates the notion of an exact copy a little bit, but I think that's a detail that can be ignored for these questions.)
History
Date User Action Args
2011-01-05 13:51:12mark.dickinsonsetrecipients: + mark.dickinson, loewis, teoliphant, ncoghlan, rupole, kermode, pitrou
2011-01-05 13:51:12mark.dickinsonsetmessageid: <1294235472.46.0.552919343366.issue10181@psf.upfronthosting.co.za>
2011-01-05 13:51:10mark.dickinsonlinkissue10181 messages
2011-01-05 13:51:09mark.dickinsoncreate