New submission from Sebastian Berg <sebast...@sipsolutions.net>:

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!

----------
components: C API
messages: 360809
nosy: seberg
priority: normal
severity: normal
status: open
title: Meaning and clarification of PyBuffer_Release()
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue39471>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to