Why does assigning into memoryview(b'abc') raise TypeError while memoryview(bytearray(b'abc')) allows it?

## Writability belongs to the exporter A `memoryview` never decides whether its memory can be written. It reports what the exporting object declared when it handed out the buffer. Immutable exporters — `bytes`, and anything else whose contents are fixed for its lifetime — set the read-only flag, and the view enforces it: ```python frozen = memoryview(b"payload") print(frozen.readonly) # True frozen[0] = 0x50 # TypeError: cannot modify read-only memory ``` Mutable exporters — `bytearray`, `array.array`, `mmap.mmap` and writable C-level buffers — export writable memory: ```python live = memoryview(bytearray(b"payload")) print(live.readonly) # False live[0] = 0x50 print(live.obj) # bytearray(b'Payload') ``` Note the last line: `view.obj` is the exporting object, and the write went straight into it. There is no commit step and no copy back. That is the point of a writable view, and it is also the reason a function that accepts one is a function that can mutate its caller's data. ## Check the flag, do not catch the error `readonly` is a plain boolean attribute, so a function that intends to write should assert on it up front rather than discovering the problem halfway through a partial write: ```python def fill(target: memoryview, value: int) -> None: if target.readonly: raise ValueError("fill() needs a writable buffer") for i in range(len(target)): target[i] = value ``` Failing at the boundary is much easier to debug than a `TypeError` raised from element 4,000 of a loop that has already modified elements 0 to 3,999. ## Two assignment rules that trip people up **Element assignment takes an int.** A default view over bytes-like memory has format `'B'` — unsigned bytes — so its elements *are* integers: ```python view = memoryview(bytearray(b"abcd")) view[0] = 120 # fine view[0] = b"x" # TypeError: memoryview: invalid type for format 'B' ``` This surprises people who expect a view to behave like a `bytearray`, where `buf[0]` reads as an `int` but slice assignment takes bytes. On a view, the element type follows the format string. **Slice assignment must match length exactly.** A view describes a fixed window; it has no mechanism to make the underlying storage bigger or smaller: ```python view = memoryview(bytearray(b"abcd")) view[0:2] = b"XY" # fine view[0:2] = b"xyz" # ValueError: memoryview assignment: # lvalue and rvalue have different structures ``` On a `bytearray` itself, `buf[0:2] = b"xyz"` would happily grow the object. Through a view it cannot, because growing means reallocating storage that other exports may be pointing at. The same reasoning is why an exported `bytearray` refuses `append` and `extend` outright. ## Handing out a view you do not want written The interesting case is memory that *is* writable but that you do not want a particular caller to touch. Wrapping it in `bytes()` would copy, defeating the purpose. `toreadonly()`, added in 3.8, produces a second view over the same memory with the read-only flag set: ```python buf = bytearray(b"secret-ish") public = memoryview(buf).toreadonly() print(public.readonly) # True print(bytes(public)) # b'secret-ish' - reading is fine ``` The caller can read and slice for free and cannot write. This is the right shape for a parsing API that hands regions of an internal buffer to plugin code: zero-copy in, no mutation out. It is not a security boundary — the caller can still reach `public.obj` — but it is a clear, cheap contract. ## Read-only does not mean unchanging A subtlety worth having ready: a read-only view over a `bytearray` guarantees that *you* cannot write through the view, not that the bytes will hold still. The owner of the `bytearray` can keep writing to it by other means, and those writes are visible through your read-only view immediately, because there is only one copy of the memory. If you need a stable snapshot, you need an actual copy — `tobytes()` — and at that point you have chosen correctness over zero-copy, which is a perfectly reasonable trade to make explicitly. The short version: `readonly` mirrors the exporter's mutability, element writes take integers under the `'B'` format, slice writes must be the same length, and `toreadonly()` is how you share writable memory without sharing the right to write it.