Why does appending to a bytearray raise BufferError while a memoryview of it is alive?

## The export count Objects that export buffers keep a count of outstanding exports. `memoryview(buf)` increments it; the view's release decrements it. While the count is non-zero, the exporter has promised that the memory it described stays at the same address with the same length, because the consumer may be a C extension holding nothing but a raw pointer. A `bytearray` stores its bytes in a single heap allocation. Growing it can `realloc` that block to a new address, and shrinking it can hand memory back. Either would break the promise, so `bytearray` checks the export count before any operation that changes its length and raises `BufferError: Existing exports of data: object cannot be re-sized`. Mutating in place is untouched: `buf[0] = 65` works with views open, and so does writing through a writable view, because neither moves the block. ## What actually trips it Everything that changes the length: `append`, `extend`, `+=`, `insert`, `pop`, `remove`, `clear`, `del buf[:n]`, and assigning a slice of a different size. Everything that does not change the length is fine. The surprise in real code is that the failing statement is usually far from the statement that created the view. ## A concrete failure: a geocoding batch with cached views Consider a geocoding batch that reads fixed-width result records into one reusable `bytearray` and keeps a small cache mapping an address key to the packed coordinate bytes. Two bugs live in that design, and both come from the same misunderstanding of what a view is. First, the cache stores `memoryview` slices of the shared buffer. Those slices are windows, not values, so the next record overwrites the memory they point at. A lookup that hits the cache then reads whatever the most recent record wrote: a stale cached value that looks plausible, points at the wrong city, and never raises. The cache must store `memoryview.tobytes()` — a real copy — or parsed values, not views. Second, when a record turns out to be longer than the buffer, the natural response is to grow the buffer with `extend`, and that raises `BufferError` because the cached views are still exporting it. The traceback points at the growth, but the cause is the cache several thousand records earlier. In a batch whose full run takes 27 minutes, this is the kind of defect that only appears near the end, on the one oversized record, long after the run looked healthy. ## Releasing deliberately `memoryview.release()` drops the export immediately. After it, any use of the view raises `ValueError: operation forbidden on released memoryview object` — which is a feature: a released view fails loudly instead of silently pointing at memory that has since moved. `memoryview` also implements the context-manager protocol, so the idiomatic form scopes the export: ```python buf = bytearray(b"abc") with memoryview(buf) as view: process(view) buf.extend(b"def") ``` Slices of a view are separate views with their own exports, so releasing the parent does not release the children; release each one you kept, or scope them all inside the same block. Do not lean on refcounting to clean up: a view referenced by a traceback held in a logging record, by a closure, or by a cache stays alive as long as that reference does. ## Diagnosing it in a running system `BufferError` is narrow enough that its presence identifies the class of bug immediately: someone is holding a buffer export of an object that something else wants to resize. The work is finding the holder. Read the code path for every `memoryview` constructed over the object, look for views escaping into caches, queues, deferred callbacks and log records, and check whether any `except` block captured a view in a traceback frame. The structural fix is almost always the same: make the boundary explicit, so that views live only inside the function that created them and anything crossing that boundary is copied with `tobytes()`. ## Design guidance Treat a writable exporter and its views as a single unit with a defined lifetime. Decide the buffer's size once, up front, so it never needs to grow; keep views inside a `with` block; and copy at any API boundary. That converts a whole family of aliasing and pinning bugs into an allocation you can see and measure.