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 kermode, loewis, mark.dickinson, ncoghlan, pitrou, rupole, teoliphant
Date 2011-01-07.03:59:23
SpamBayes Score 9.016908e-06
Marked as misclassified No
Message-id <1294372767.02.0.395830819855.issue10181@psf.upfronthosting.co.za>
In-reply-to
Content
@Antoine: I actually had a closer look at the way dup_buffer is used, and I think it is currently legitimate (including for the anonymous memory case). It just isn't documented very well. For the "FromBuffer" case, it assumes the calling code already invoked GetBuffer as necessary when initialising the view, and for the various internal uses the dup_buffer call is immediately preceded by a GetBuffer call when view->obj is not NULL.

@Mark: I don't think that follows. PEP 3118 says that exporting objects own that memory, but it doesn't say that clients have to treat the structures as read-only. The only thing clients are obligated to do is pass the same Py_buffer address to ReleaseBuffer that was passed to GetBuffer. If the exporter actually needs to release buffer specific resources, then it should maintain an internal data structure keyed off the Py_buffer address.

The one thing clients really shouldn't mess with is the obj field (since ReleaseBuffer needs that to find the correct release method to invoke), but the PEP is obviously silent on that matter since it doesn't even acknowledge the existence of that field.
History
Date User Action Args
2011-01-07 03:59:27ncoghlansetrecipients: + ncoghlan, loewis, teoliphant, mark.dickinson, rupole, kermode, pitrou
2011-01-07 03:59:27ncoghlansetmessageid: <1294372767.02.0.395830819855.issue10181@psf.upfronthosting.co.za>
2011-01-07 03:59:23ncoghlanlinkissue10181 messages
2011-01-07 03:59:23ncoghlancreate