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 seberg
Recipients seberg
Date 2020-01-27.22:14:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1580163259.11.0.807397733698.issue39471@roundup.psfhosted.org>
In-reply-to
Content
The current documentation of ``PyBuffer_Release()`` and the PEP is a bit fuzzy about what the function can and cannot do.

When an object exposes the buffer interface, I believe it should always return a `view` (in NumPy speak) of its own data, i.e. the data exposed by the object is also owned by it directly.

On the other hand the buffer view _itself_ has fields such as `strides`, etc. which may need allocating.

In other words, I think `PyBuffer_Release()` should be documented to deallocate/invalidate the `Py_buffer`. But, it *must not* invalidate the actual memory it points to. If I copy all information out of the `Py_buffer` and then free it, the copy must still be valid.

I think this is the intention, but it is not spelled out clear enough, it is also the reason for the behaviour of the "#s", etc. keyword argument parsers failing due to the code:

    if (pb != NULL && pb->bf_releasebuffer != NULL) {
        *errmsg = "read-only bytes-like object";
        return -1;
    }

which in turn currently means NumPy decides to _not_ implement bf_releasebuffer at all (leading to very ugly work arounds).

I am happy to make a PR, if we can get to a point where everyone is absolutely certain that the above interpretation was always correct, we could clean up a lot of code inside NumPy as well!
History
Date User Action Args
2020-01-27 22:14:19sebergsetrecipients: + seberg
2020-01-27 22:14:19sebergsetmessageid: <1580163259.11.0.807397733698.issue39471@roundup.psfhosted.org>
2020-01-27 22:14:19seberglinkissue39471 messages
2020-01-27 22:14:18sebergcreate