Skip to content

Make the data views writable#536

Draft
jholveck wants to merge 2 commits into
BoboTiG:mainfrom
jholveck:memoryview-tweaks
Draft

Make the data views writable#536
jholveck wants to merge 2 commits into
BoboTiG:mainfrom
jholveck:memoryview-tweaks

Conversation

@jholveck
Copy link
Copy Markdown
Contributor

@jholveck jholveck commented Jun 2, 2026

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.

Changes proposed in this PR

  • Tests added/updated
  • Documentation updated
  • Changelog entry added
  • ./check.sh passed

jholveck added 2 commits June 1, 2026 20:35
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.
In the release notes, one change was accidentally in PR BoboTiG#535 instead,
and one change was omitted entirely.  Fix.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant