Antoine Pitrou wrote:
Nick Coghlan <ncoghlan <at> gmail.com> writes:
I don't see anything wrong with the PEP 3118 protocol.
Apart from the fact that:
- it uses something (Py_buffer) which is not a PyObject and has totally
different allocation/lifetime semantics (which makes it non-trivial to adapt to
for anyone used to the rest of the C API)
* this is a non-issue. The Py_buffer struct is just a place-holder
for a bunch of variables. It could be a Python-object but that was seen
as unnecessary.
- it has unsolved issues like allocation of the underlying shape and strides
members
* this is false. It does specify how this is handled.
- it doesn't specify how to obtain e.g. a sub-buffer, or even duplicate an
existing one (which seem to be rather fundamental actions to me)
* this is not part of the PEP. Whether it's a deficiency or not is
open to interpretation.
... I agree there's nothing wrong with it!
I'm glad you agree.
That Py_buffer describes the *whole* data store, but a memoryview slice
may only be exposing part of it - so while the info in the Py_buffer is
accurate for the underlying object, it is *not* accurate for the
memoryview itself.
And the problem here is that Py_buffer is/was (*) not flexible enough to allow
easy modification in order to take a sub-buffer without some annoying problems.
You are confusing the intent of the memoryview with the Py_buffer struct.
-Travis
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
