PEP 688: Enhance and clarify the specification #2917
Conversation
Co-authored-by: Petr Viktorin <encukou@gmail.com>
| as was returned by ``__buffer__``. It is | ||
| also possible to call ``__release_buffer__`` on a C class that | ||
| implements ``bf_releasebuffer``. |
There was a problem hiding this comment.
This might be a different concern, but: what does calling __release_buffer__ on such a class do?
There was a problem hiding this comment.
It calls bf_releasebuffer, if called with the same memoryview that __buffer__ returned: https://github.com/JelleZijlstra/cpython/blob/pep688v2/Objects/typeobject.c#L7672. In fact it calls memoryview.release(), which takes care of ensuring that we don't double-call bf_releasebuffer (which would likely segfault).
There was a problem hiding this comment.
Would it be worth calling out in the PEP text that some calls to .__release_buffer__() will not result in a call to the underlying bf_releasebuffer slot? (e.g. if you call it twice, or call it with the wrong memoryview) I think the blanket statement that "The interpreter will ensure that such errors do not lead to memory leaks or memory safety violations" is sufficient, but happy to add more detailed wording.
There was a problem hiding this comment.
IMO it would be good to specify if these situations raise an exception, warn, or are silent no-ops.
@encukou this is an attempt to clarify some of the areas you
brought up in https://discuss.python.org/t/pep-688-take-2-making-the-buffer-protocol-accessible-in-python/19756/15?u=jelle
and subsequent posts. Would you mind taking a look to see if
this addresses your concerns?