Author skrah
Recipients jcon, kristjan.jonsson, mark.dickinson, ncoghlan, paul.moore, petri.lehtinen, pitrou, pv, rupole, skrah, teoliphant, vstinner
Date 2012-01-28.22:44:49
SpamBayes Score 2.92645e-07
Marked as misclassified No
Message-id <>
In-reply-to <1327784231.8904.10.camel@localhost.localdomain>
Antoine Pitrou <> 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
pep-3118 repo.]

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?
Date User Action Args
2012-01-28 22:44:50skrahsetrecipients: + skrah, teoliphant, paul.moore, mark.dickinson, ncoghlan, rupole, pitrou, kristjan.jonsson, vstinner, pv, jcon, petri.lehtinen
2012-01-28 22:44:49skrahlinkissue10181 messages
2012-01-28 22:44:49skrahcreate