homepage

Antoine Pitrou <report@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:
http://bugs.python.org/issue10181#msg125462
For instance, here the macros are not excluded:
http://hg.python.org/cpython/file/3292cc222d5c/Include/memoryobject.h
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
pep-3118 repo.]
As for the two macros specifically, I know Pauli was using them:
http://bugs.python.org/issue10181#msg139775
> > 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?