Greg Ewing <greg.ewing <at> canterbury.ac.nz> writes: > > 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.
If the memoryview wasn't holding onto a Py_buffer, one couldn't rely on its length or anything else because the underlying object could be mutated at any moment (even by another thread). It would make memoryview objects basically unusable for anything except bytes objects (which are immutable). > 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 already what is being done, but that's got nothing to do with the problem at hand. We are talking about slicing the memoryview, not taking a (non-sliced) buffer of it. > It's not needed for Python getitem > and setitem calls. What is needed for Python getitem and setitem calls is proper shape information in the embedded Py_buffer struct, otherwise memoryview slices are buggy. In the case of a memoryview slice, the proper shape information can only be computed *after* the Py_buffer is obtained. > It sounds to me like whoever wrote the memoryview implementation > didn't understand how the buffer interface is meant to be used. Perhaps, perhaps not, but without any concrete suggestion we won't go anywhere. As I said, I don't think it would be foolish to revamp the current spec and/or implementation /if we have a precise plan of how to do better/. The /if/ part is important :-) Regards Antoine. _______________________________________________ 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
