Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> /* info->obj is either NULL or a borrowed reference. This
> reference should not be decremented in PyBuffer_Release(). */
The semantics of PyMemoryView_FromBuffer() are problematic. This function
is the odd one in memoryobject.c since it's the only function that breaks
the link in consumer -> exporter chains. This has several consequences:
1) One can't rely on the fact that 'info' has PyBUF_FULL information.
This is a major inconvenience and the reason for *a lot* of code
in memoryobject.c that reconstructs PyBUF_FULL information.
2) One has to make a decision whether PyMemoryView_FromBuffer() steals
the reference to view.obj or treats it as a borrowed reference.
My view on this is that it's safer to treat it as a borrowed reference.
Additionally, I can't see a scenario where PyMemoryView_FromBuffer(info)
could be used for creating a non-temporary memoryview with automatic
decref of info.obj: If 'info' is allocated on the stack, then the
memoryview shouldn't be returned from a function. If 'info' is allocated
on the heap, then who frees 'info' when the memoryview is deallocated?
Permanent memoryviews can now be safely created with PyMemoryView_FromMemory().
PyMemoryView_FromBuffer() isn't really that useful any more.
It's hard to document all this in a few lines. Perhaps you can open an
issue for this?
Stefan Krah
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4