Open milesgranger opened 3 months ago
And lastly, I should also note that if I do PyMemoryView_FromObject
first and use that result into PyObject_GetBuffer
instead, then it will happily say that bytes are writable now as well as bytearray. (Then the weird delayed updating issue comes back for bytes
)
Hi,
(disclaimer, I'm new to PyPy so could very well be missing something obvious)
I'm the maintainer of cramjam, looking into this issue https://github.com/milesgranger/cramjam/issues/142 with draft PR at https://github.com/milesgranger/cramjam/pull/143
In short, cramjam currently, and regrettably, ignores the
readonly
portion ofPy_buffer
. (Aiming to change this in v3). So it will happily write tobytes
for example, CPython doesn't appear to take issue with this, but PyPy does.[not directly relevant side-bar]
If I try to maintain this behavior it kinda works. Very strange behavior in that when
bytes
is used, on this line in the tests,output
will remain the original value. (For exampleb'0' * 23
) But when debugging it'll quickly change to the expected value (ie b'\xff\x06\x00\x00sNaPpY\x01\x05\x00\x00\xd2\x8f%I\x00').Even more entertainment can be discovered if I adapt the test to use a while loop which keeps checking the assertion until eventually output is updated to the expected value.
But okay, that's maybe an issue in and of itself for PyPy as this currently works in CPython.. something strange going on there but I'm less interested in going down that route since it's the wrong thing to do anyhow.
[end side-bar]
I then try to go ahead and do it right by respecting the readonly field of
Py_buffer
, but I quickly discover types that should give a writable buffer are not, for example bytearray:In PyPy 3.9:
But in CPython: this works as expected:
Edit:
For clarity, I'm trying to access the buffer via
PyObject_GetBuffer(...., PyBUF_CONTIG_RO)
which ought to give the correct readonly setting: https://docs.python.org/3/c-api/buffer.html#compound-requests