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, pv, rupole, teoliphant
Date 2011-02-14.14:03:09
SpamBayes Score 6.904371e-05
Marked as misclassified No
Message-id <1297692190.55.0.441884504461.issue10181@psf.upfronthosting.co.za>
In-reply-to
Content
If it helps, one way to think of it is that post-redesign, the PyManagedBuffer would be the "real" API object, with Py_buffer merely a way for data exporters to provide the information needed to initialise the managed buffer properly. (That actually fairly accurately tracks the origin of the Py_buffer struct - to avoid huge numbers of output variables in the GetBuffer API calls)

Is such a solution ideal? No, but it would be significantly better than what we have now. If the PEP had been implemented as written, we would also have been much better off, but given that we failed to pick up the discrepancies between spec and implementation at the time, we're now stuck with trying to improve the situation without breaking backwards compatibility.

Since I now agree with your diagnosis that the heart of the problem is the fact that Py_buffer contains lots of pointers and thus is difficult to copy safely, wrapping it in a PyObject (without adding any additional behaviour) in order to minimise copying seems like the most obvious solution.
History
Date User Action Args
2011-02-14 14:03:10ncoghlansetrecipients: + ncoghlan, loewis, teoliphant, mark.dickinson, rupole, kermode, pitrou, pv
2011-02-14 14:03:10ncoghlansetmessageid: <1297692190.55.0.441884504461.issue10181@psf.upfronthosting.co.za>
2011-02-14 14:03:10ncoghlanlinkissue10181 messages
2011-02-14 14:03:09ncoghlancreate