You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve #78959
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 commentedon 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_contiguousandf_contiguousrespectively, of a memoryview object.Using the method
castallows one to specify a shape but does not allowto specify whether row or column major:
The result object is believed to be row-major and little can be done
to correct it:
mattip commentedon Sep 24, 2018
This could be done via a
shapekwarg tocastlgautier commentedon Sep 28, 2018
@mattip : do you mean that it can currently be achieved by calling
castwith a specific shape parameter ? If the case, how so ?mattip commentedon Sep 29, 2018
Sorry, I meant a "strides" keyword. "shape" is already a valid keyword
lgautier commentedon 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 commentedon Dec 30, 2018
Bump.
What are the next steps here ?
skrah commentedon 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 commentedon Dec 30, 2018
Wait. Isn't a
memoryviewmemerely 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
tobytesis doing, this delegates the justification for excluding non 'C' views it. Then I do not understand the rationale behindmemoryview.tobytes's exclusive relationshop to C-contiguous arrays. A memmoryview is a window on a memory region (a Python buffer), and one would expecttobytesto just return bytes for it (in whatever bytes/strides) the memoryview is originally in.6 remaining items
lgautier commentedon Aug 31, 2019
Bump.
Is there anything I could do to move this forward (as in write and submit a patch for review) ?
lgautier commentedon 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 commentedon May 13, 2022
Note the bpo issue 35845 is now #80026 on github
serhiy-storchaka commentedon Jul 13, 2026
Opened #153663.
It adds a keyword-only
orderparameter tomemoryview.cast(); withorder='F'you get a zero-copy Fortran-contiguous (column-major) view of a flat buffer, mirroringmemoryview.tobytes(order=...).gh-78959: Add order parameter to memoryview.cast() (GH-153663)
pythongh-78959: Add order parameter to memoryview.cast() (pythonGH-15…