Antoine Pitrou wrote:
> Why should it need two? Why couldn't the embedded Py_buffer fullfill all the
> needs of the memoryview object?
Two things here:
1) The memoryview should *not* be holding onto a Py_buffer
in between calls to its getitem and setitem methods. It
should request one from the underlying object when needed
and release it again as soon as possible.
2) The "second" Py_buffer referred to above only needs to
be materialized when someone makes a GetBuffer request on
the memoryview itself. It's not needed for Python getitem
and setitem calls. (The implementation might choose to
implement these by creating a temporary Py_buffer, but
again, it would only last as long as the call.)
> If the memoryview can't be a relatively thin
> object-oriented wrapper around a Py_buffer, then this all screams failure to me.
It shouldn't be a wrapper around a Py_buffer, it should be a
wrapper around the buffer *interface* of the underlying object.
> In all honesty, I admit I am annoyed by all the problems with the buffer API /
> memoryview object, many of which are caused by its utterly bizarre design
It sounds to me like whoever wrote the memoryview implementation
didn't understand how the buffer interface is meant to be used.
That doesn't mean there's anything wrong with the buffer interface.
I have some doubts myself about whether it needs to be as
complicated as it is, but I think the basic idea is sound:
that Py_buffer objects are ephemeral, to be obtained when
needed and not kept for any longer than necessary.
--
Greg
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