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 skrah
Recipients arigo, skrah
Date 2014-06-16.17:49:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20140616174940.GA31240@sleipnir.bytereef.org>
In-reply-to <1402932024.69.0.694479216836.issue21778@psf.upfronthosting.co.za>
Content
Yes, PyBuffer_FillInfo() is a bit confusing:  The canonical usage *looks* as
if "flags" were somehow used in the Py_buffer struct to mark a buffer as having
certain capabilities:

Modules/_io/bufferedio.c:
-------------------------

    if (PyBuffer_FillInfo(&buf, NULL, start, len, 0, PyBUF_CONTIG) == -1)
        return -1;
    memobj = PyMemoryView_FromBuffer(&buf);

What really goes on since Python 3.3 is that memobj is a memoryview
with (shape,strides,format), since missing Py_buffer values are
reconstructed.

So all memoryviews -- when acting as an exporter as in this example --
have PyBUF_FULL capabilities.  To make that clear, we should actually
change the PyBUF_CONTIG in the above example to PyBUF_FULL.  Then
the mental model is:

    PyBuffer_FillInfo(..., PyBUF_FULL)

                 ^
                 |  "Request" full buffer to export.

               memobj

                 ^
                 |  Request anything from PyBUF_SIMPLE to PyBUF_FULL. Note
                 |  that e.g. with PyBUF_SIMPLE the consumer's shape and
                 |  strides will be NULL!

              Consumer

And that model is consistent with the usage of PyBuffer_FillInfo() inside
a getbufferproc, where "flags" of course can be anything.
History
Date User Action Args
2014-06-16 17:49:41skrahsetrecipients: + skrah, arigo
2014-06-16 17:49:41skrahlinkissue21778 messages
2014-06-16 17:49:41skrahcreate