Author pv
Recipients kermode, loewis, mark.dickinson, ncoghlan, pitrou, pv, rupole, teoliphant
Date 2011-02-13.15:34:16
SpamBayes Score 2.78373e-09
Marked as misclassified No
Message-id <>
Ok, good, that diversion was then avoided :)


So, am I on the right track that there would not be many objections to clarifying the docs of Py_buffer spec by stating:

- For each buffer yielded by `bf_getbuffer`, `bf_releasebuffer`
  is called exactly once.

  Each `bf_releasebuffer` call is guaranteed to get the same
  view->internal pointer as filled in previously by the
  corresponding `bf_getbuffer`.

  All other fields in `Py_buffer` may be modified by the consumer,
  and `bf_releasebuffer` may not assume they contain valid data.

- The exporter of the buffer must ensure that apart from the contents
  of the memory pointed to by `buf`, the contents of the returned
  Py_buffer (format, strides, shape, etc.) remain unchanged.

If the latter is not true, it will lead to no end of trouble in e.g. multithreaded programs.

What about the more strict requirement:

- `bf_releasebuffer` is guaranteed that all fields except `obj`
  are not modified?

This could simplify implementation of exporters, and I suspect that MemoryViewObject is a special case, as most consumers probably would not want to make such modifications.

I can try preparing an updated patch based on some combination of the above, taking into account your comments.

BTW, should I take this discussion to Python-dev? So far, I kept it here, as this bug report seemed to be about general issues in the current implementation and spec.
Date User Action Args
2011-02-13 15:34:19pvsetrecipients: + pv, loewis, teoliphant, mark.dickinson, ncoghlan, rupole, kermode, pitrou
2011-02-13 15:34:19pvsetmessageid: <>
2011-02-13 15:34:17pvlinkissue10181 messages
2011-02-13 15:34:16pvcreate