The buffer protocol is accounting for the row-major or column-major arrays, and that information is shown in the attributes, c_contiguous and f_contiguous respectively, of a memoryview object.
Using the method cast allows one to specify a shape but does not allow
to specify whether row or column major:
# column-major 3x2 array of bytes that was serialized
b = bytearray([1,2,3,4,5,6])
mv = memoryview(b)
mv_b = mv.cast('b', shape=(3,2))
The result object is believed to be row-major and little can be done
to correct it:
>>> mv_int.c_contiguous
True
>>> mv_int.c_contiguous = False
AttributeError: attribute 'c_contiguous' of 'memoryview' objects is not writable
memoryview.cast() was originally meant to be a faster version of tobytes(), which always converts to C-contiguous.
The 'shape' keyword was added because it is odd if you can cast from ND-C to 1D-Bytes but not back.
I'm not sure if we should introduce that feature, just pointing out that the original decision to exclude non 'C' views was deliberate.
lgautier commented on Dec 30, 2018
lgautiermannequin
MannequinAuthor
More actions
Wait. Isn't a memoryview memerely a Python object for a buffer inferface, whatever its valid attributes or flags might be ?
The perceived oddness that lead to the addition of the keyword 'shape' was a good initial instinct that something was off, but this is an incomplete workaround .
If the rationale was to follow what tobytes is doing, this delegates the justification for excluding non 'C' views it. Then I do not understand the rationale behind memoryview.tobytes's exclusive relationshop to C-contiguous arrays. A memmoryview is a window on a memory region (a Python buffer), and one would expect tobytes to just return bytes for it (in whatever bytes/strides) the memoryview is originally in.
It adds a keyword-only order parameter to memoryview.cast(); with order='F' you get a zero-copy Fortran-contiguous (column-major) view of a flat buffer, mirroring memoryview.tobytes(order=...).
Activity
lgautier commented on Sep 23, 2018
The buffer protocol is accounting for the row-major or column-major arrays, and that information is shown in the attributes, c_contiguous and f_contiguous respectively, of a memoryview object.
Using the method cast allows one to specify a shape but does not allow
to specify whether row or column major:
# column-major 3x2 array of bytes that was serialized b = bytearray([1,2,3,4,5,6]) mv = memoryview(b) mv_b = mv.cast('b', shape=(3,2))The result object is believed to be row-major and little can be done
to correct it:
mattip commented on Sep 24, 2018
This could be done via a shape kwarg to cast
lgautier commented on Sep 28, 2018
@mattip : do you mean that it can currently be achieved by calling cast with a specific shape parameter ? If the case, how so ?
mattip commented on Sep 29, 2018
Sorry, I meant a "strides" keyword. "shape" is already a valid keyword
lgautier commented on Sep 29, 2018
Wouldn't a contiguity argument ('C' or 'F') be simpler ?
(Independently, an argument strides is likely also missing from "cast").
Do you know what are the next possible steps here ? Bring this to the python-dev list ? Submit a patch ?
lgautier commented on Dec 30, 2018
Bump.
What are the next steps here ?
skrah commented on Dec 30, 2018
memoryview.cast() was originally meant to be a faster version of tobytes(), which always converts to C-contiguous.
The 'shape' keyword was added because it is odd if you can cast from ND-C to 1D-Bytes but not back.
I'm not sure if we should introduce that feature, just pointing out that the original decision to exclude non 'C' views was deliberate.
lgautier commented on Dec 30, 2018
Wait. Isn't a memoryview memerely a Python object for a buffer inferface, whatever its valid attributes or flags might be ?
The perceived oddness that lead to the addition of the keyword 'shape' was a good initial instinct that something was off, but this is an incomplete workaround .
If the rationale was to follow what tobytes is doing, this delegates the justification for excluding non 'C' views it. Then I do not understand the rationale behind memoryview.tobytes's exclusive relationshop to C-contiguous arrays. A memmoryview is a window on a memory region (a Python buffer), and one would expect tobytes to just return bytes for it (in whatever bytes/strides) the memoryview is originally in.
6 remaining items
lgautier commented on Aug 31, 2019
Bump.
Is there anything I could do to move this forward (as in write and submit a patch for review) ?
lgautier commented on Oct 3, 2021
Bump.
I am still stumbling on that issue. I have a workaround by importing numpy but that's a rather large dependency for that one little thing.
I see that the related issue https://bugs.python.org/issue35845 opened later has later discussion entries.
mattip commented on May 13, 2022
Note the bpo issue 35845 is now #80026 on github
serhiy-storchaka commented on Jul 13, 2026
Opened #153663.
It adds a keyword-only order parameter to memoryview.cast(); with order='F' you get a zero-copy Fortran-contiguous (column-major) view of a flat buffer, mirroring memoryview.tobytes(order=...).
gh-78959: Add order parameter to memoryview.cast() (GH-153663)
pythongh-78959: Add order parameter to memoryview.cast() (pythonGH-15…