How do you store a uuid.UUID as sixteen bytes and rebuild the object later?

`uuid.UUID` is an immutable value object wrapping a single 128-bit integer. Everything you can get out of it is a *view* of that one number, and everything you can put into the constructor is a way of *spelling* it. Knowing the four spellings, and which of them you actually persist, is most of what this question is after. ### The read-only views Given `u = uuid.UUID("f81d4fae-7dec-11d0-a765-00a0c91e6bf6")`: * `u.bytes` — the sixteen bytes, most significant first. This is the canonical binary form. * `u.bytes_le` — the same sixteen bytes with the first three fields byte-swapped to little-endian. It exists for the Microsoft GUID layout, and mixing it up with `u.bytes` silently produces a different, wrong-looking identifier that still parses. * `u.hex` — 32 lowercase hex characters, no hyphens. * `u.int` — one Python `int` holding all 128 bits. * `str(u)` — the 36-character hyphenated text; `u.urn` wraps that as `urn:uuid:...`. * `u.fields`, `u.version`, `u.variant` — the structural decomposition. The object is genuinely immutable: assigning to an attribute raises `TypeError`. Because it is immutable it is hashable and orders by its integer value, so `UUID` objects work directly as dict keys, in sets, and in `sorted()` without converting to strings first. ### The constructor `uuid.UUID` takes exactly one of `hex`, `bytes`, `bytes_le`, `fields` or `int`; passing none or more than one is a `TypeError`. `hex` is also the first positional parameter, which is why `uuid.UUID(some_string)` reads naturally. The text parser is forgiving about presentation and strict about content: it strips a `urn:uuid:` prefix, surrounding braces and hyphens wherever they appear, then requires exactly 32 hex digits. Anything else — a truncated string, a stray letter, sixteen-plus-one bytes — raises `ValueError`. That strictness is worth leaning on: parsing user input through `uuid.UUID` is a genuine validation step, not a formality, and it belongs in a `try`/`except ValueError`. There is also `uuid.UUID(int=..., version=N)`, which stamps the version and variant bits over whatever you supplied. Use it only when you are deliberately constructing a value in a known layout. ### Sixteen bytes against thirty-six characters The hyphenated text form is 36 characters, and stored as ASCII that is 36 bytes plus whatever length overhead the container adds; the binary form is 16. So the text costs more than twice as much everywhere it is repeated — in a stored value, in a message payload, in a memory-resident collection of millions of ids. It also makes equality a string comparison rather than a sixteen-byte one, and if the text was ever written in two different presentations — upper case in one place, braces in another — two spellings of the same identifier stop comparing equal at the storage layer even though `uuid.UUID` would parse both to the same object. The counter-argument is human: a binary blob does not read back in a console session, does not paste into a support ticket, and needs a decode step in every ad-hoc query. The usual compromise is binary at rest with the text form at the edges — `str(u)` on the way out to a log line or an API response, `uuid.UUID(...)` on the way in, and `u.bytes` in between. ### Round-tripping Every view has an exact inverse, and this is worth demonstrating rather than asserting: ```python import uuid u = uuid.uuid4() assert uuid.UUID(bytes=u.bytes) == u assert uuid.UUID(int=u.int) == u assert uuid.UUID(u.hex) == u assert uuid.UUID(str(u)) == u ``` The one that is *not* symmetric is `bytes_le`: `uuid.UUID(bytes=u.bytes_le)` parses happily and gives you a different UUID. If you take bytes from a system that hands out GUIDs in the little-endian layout, feed them to the `bytes_le` keyword, and remember that `u.bytes` is what everything else means by "the bytes of this UUID".