This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients docs@python, ezio.melotti, martin.panter, r.david.murray, serhiy.storchaka
Date 2015-04-01.11:33:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
After doing a bit of reading and experimenting, I think we should at least restrict bytes-like objects to “C-contiguous”. Any looser definition risks memoryview(byteslike).tobytes() returning the bytes in a different order than their true in-memory order. Fortran-style contiguous arrays aren’t enough:

>>> import _testbuffer, sys
>>> fortran = memoryview(_testbuffer.ndarray([11, 12, 21, 22], format="B", flags=0, shape=[2, 2], strides=[1, 2], offset=0))
>>> fortran.f_contiguous
>>> fortran.c_contiguous
>>> fortran.tolist()
[[11, 21], [12, 22]]
>>> tuple(bytes(fortran))
(11, 21, 12, 22)
>>> sys.stdout.buffer.write(fortran)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: memoryview: underlying buffer is not C-contiguous

So I am proposing a patch which:

* Restricts the bytes-like object definition to C-contiguous buffers
* Explains what I think is actually meant by “contiguous” in the C API buffer protocol page. Turns out it is generally a more strict definition than I originally assumed.
* Explains why memoryview.tobytes() is out of order for non C-contiguous buffers
* Has a couple other fixes taking into acount memoryview.tolist() doesn’t work for zero dimensions, and is nested for more than one dimension
Date User Action Args
2015-04-01 11:33:05martin.pantersetrecipients: + martin.panter, ezio.melotti, r.david.murray, docs@python, serhiy.storchaka
2015-04-01 11:33:05martin.pantersetmessageid: <>
2015-04-01 11:33:05martin.panterlinkissue23756 messages
2015-04-01 11:33:05martin.pantercreate