What does memoryview give you that slicing a bytes object does not?

### Slicing copies; viewing does not `data[10:20]` on a `bytes` or `bytearray` object allocates a new object and memcpys ten bytes into it. That is cheap at ten bytes and ruinous at ten megabytes, and it is what `memoryview` exists to avoid. `memoryview(data)[10:20]` allocates only a small view object that records a pointer, a length, an item format and a reference to the exporting object. No payload bytes move. A `memoryview` is a *window*, not a container. It has no storage of its own. Everything it can do is defined by the **buffer protocol**, the C-level interface an object implements to say "here is my memory, here is its shape, and here is whether you may write to it". `bytes`, `bytearray`, `array.array`, `mmap.mmap` and many C extension types all export it; since Python 3.12 the concept also has a name in the standard library, `collections.abc.Buffer`. ### Writing through a view Because a view points at the original memory, assigning through a view of a **mutable** exporter edits the original: given `view = memoryview(frame)` over a `bytearray`, `view[0] = 0xFF` changes `frame`. Views of immutable exporters are read-only — `memoryview(b"x")[0] = 1` raises `TypeError: cannot modify read-only memory` — and `readonly` reports which kind you hold. `toreadonly()` hands out a read-only view of writable memory, which is how you share a buffer without granting write access. This is the whole point in parsing code: you can walk a large received frame, hand each field to a handler as a view, and let a handler that must mutate do so in place, with zero intermediate allocations. ### cast, and why len() stops meaning bytes `cast(fmt)` reinterprets the same bytes under a different item format: `view.cast("H")` treats the region as unsigned 2-byte integers, `cast("i")` as 4-byte signed ones, `cast("B")` returns to plain octets. Nothing is copied or converted — only the interpretation changes. Consequently `len(view)` counts **items, not bytes**: a 16-byte region is `len() == 16` as `"B"` and `len() == 8` after `cast("H")`. The byte count lives in `nbytes`, the per-item width in `itemsize`, and the code in `format`. `cast` requires a C-contiguous view whose current format is plain bytes, and multi-byte formats use the machine's native byte order — which is why a view cast is the wrong tool for decoding a fixed-endian wire format. ### tobytes and release `tobytes()` is the deliberate exit hatch: it copies the viewed region into a new immutable `bytes` object. Call it exactly when you *want* the copy — at an API boundary, or when you intend to keep a small field long after the big source buffer should have been freed. `release()` tears the view down immediately rather than waiting for garbage collection, and a `memoryview` also works as a context manager, so `with memoryview(buf) as view:` releases on exit. Releasing matters because a live export **locks the exporter against resizing**: while any view of a `bytearray` is outstanding, `buf += b"x"`, `buf.extend(...)` or a length-changing slice assignment raises `BufferError: Existing exports of data: object cannot be re-sized`. CPython refuses because a reallocation would move the memory and leave the view dangling. After the view is released, the same resize succeeds. Any operation on a released view raises `ValueError`. ### Reading the view itself Four attributes describe any view and are worth naming in an answer: `readonly` says whether writes are permitted, `format` gives the item code, `itemsize` the width of one item in bytes, and `nbytes` the total size of the region regardless of format. Together they let you assert what you are holding before you touch it, which matters because a view arriving from elsewhere may be read-only, may already be cast, or may be over an exporter you did not create. Views can also describe more than a flat run of bytes — `shape`, `strides` and `ndim` exist for multi-dimensional and non-contiguous buffers exported by C extensions — but `cast` and the simple slicing described here require a contiguous one-dimensional region. After `release()`, every operation on the view raises `ValueError`, so a released view fails loudly rather than reading freed memory. ### What it is not A `memoryview` is not an I/O buffer, and it is not a general-purpose array. It does not convert types, does not resize, does not own memory, and does not make a slow loop fast on its own — a per-item Python loop over a view is roughly as slow as any other Python loop. Its payoff is allocation and copy avoidance on large regions: parsing a frame in place, filling a preallocated destination with a `readinto`-style call and then handing out subviews, or passing a region into a C extension that can operate on foreign memory. Below a few kilobytes, plain slicing is usually simpler and fast enough, and the view's bookkeeping — release discipline, resize locking, item-vs-byte lengths — is real complexity you should only take on when the copy actually hurts.