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
* Make the data views writable.
Previously (while working on 11.0), we changed the .bgra and .rgb
attributes to be read-only memoryviews. We also removed the .raw
attribute.
The main reason we made the memoryviews read-only is so that we don't
have to worry about cached values of .pixels and .rgb being in-sync
with the underlying buffer, if users mutated the pixel data.
However, I now realize that this takes away a possible valuable use
case: ctypes. ctypes can only create an array (or pointer) from a
buffer if it's writable; it doesn't support a read-only version.
Previously, users could make a ctypes pointer using the .raw
attribute. The new API doesn't give them that ability, without
copying the data (or using ctypes' from_address, which is perilous).
Read-only buffers also trigger a warning from PyTorch, although it's
clearly-written and only is printed once.
This PR, as it stands, makes the `.bgra` and `.rgb` properties return
writable memoryviews. (It also restores `.raw`, this time as a
deprecated alias of bgra, since there's no pressing need to remove the
name entirely.)
It also documents that, while these memoryviews are writable, actually
modifying the data may cause undefined behavior.
There's alternatives, of course. Instead of what I've got here,
ChatGPT instead suggests that we leave .bgra and .rgb read-only (as
they were in 10.2, since they were `bytes` objects), and to add a
property like `.writable_bgra` or something. Its argument is as
follows:
> The problem with making .bgra writable and saying “mutating is UB
> [undefined behavior]” is that Python users will absolutely see
> writable buffer and think “cool, in-place image editing.” That’s
> not UB in the fun C sense; it’s more like “congratulations, you have
> a weird cache-invalidation footgun.” The API shape would be lying a
> little.
I'm making this PR for discussion and consensus on the best way to go.
* Update release notes
In the release notes, one change was accidentally in PR #535 instead,
and one change was omitted entirely. Fix.
* Apply suggestions from code review
Co-authored-by: Halldor Fannar <halldorfannar@users.noreply.github.com>
---------
Co-authored-by: Halldor Fannar <halldorfannar@users.noreply.github.com>
0 commit comments