[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
report at bugs.python.org
Sat Jan 28 23:44:50 CET 2012
Stefan Krah <stefan-usenet at bytereef.org> added the comment:
Antoine Pitrou <report at bugs.python.org> wrote:
> > a) Make all functions and the two buffer access macros part
> > of the limited API again.
> Hmm, I don't think buffer access macros should be part of the limited
> API. If they are truely important (which I doubt), we should have
> equivalent functions for them.
I thought the whole Py_buffer API was only temporarily removed from the
limited API until the issues were sorted out:
For instance, here the macros are not excluded:
Since the issues seem resolved in general, I thought it was time to
restore the previous state. [I just noticed that I didn't revert all
of Martin's changes, so xxlimited currently does not build in the
As for the two macros specifically, I know Pauli was using them:
> > I think it might be OK to defer the decision about Py_MEMORYVIEW_C etc.,
> > since the comment already says "... Don't access their fields directly.".
> My question is whether there is any point in making these flags. Does
> 3rd-party code want to manipulate memoryview internals, instead of
> querying the Py_buffer?
The flags are primarily for the memoryview itself to avoid repeated calls
to PyBuffer_IsContiguous(). So when 3rd-party uses PyMemoryView_GET_BUFFER
to get the view and also needs to determine the contiguity type, that
code could also use the flags.
Pauli: If you are still following the issue, do you think having access
to contiguity flags is useful for 3rd-party code or not?
Python tracker <report at bugs.python.org>
More information about the Python-bugs-list