How does hashlib's update, digest and hexdigest cycle hash data incrementally?
answer
- The object accumulates; it is not a function
- Chunked feeding equals one big call
- Two renderings of the same value
- Reading a digest does not reset it
- Bytes in, TypeError on str
basics
~20 sA hashlib hash object accumulates bytes across repeated update() calls, so feeding data in chunks matches hashing it in one call. digest() returns the raw bytes, hexdigest() the same value as a hex string; reading either does not reset the object.
solid answer
~40 s`hashlib.sha256()` (or `hashlib.new("sha256")`) returns a mutable hash object, not a number. Every `update()` call appends to the running state, so `h.update(a); h.update(b)` is identical to `hashlib.sha256(a + b)` — that is what lets you hash a stream you never hold in memory. `digest()` returns `digest_size` raw bytes (32 for SHA-256); `hexdigest()` returns the same bytes rendered as a lowercase hex `str` of twice that length. Both are read-only snapshots: you can call them, keep updating, and call again. Input must be bytes-like — passing a `str` raises `TypeError`. `copy()` forks the current state, which is how you hash many messages that share a long common prefix without re-reading it.
code
python · 8 linesimport hashlib
h = hashlib.sha256()
h.update(b"lat,lon\n")
h.update(b"51.5,-0.12\n")
print(h.hexdigest() == hashlib.sha256(b"lat,lon\n51.5,-0.12\n").hexdigest())
print(len(h.digest()), h.digest_size, h.name)
print(h.hexdigest()[:16])go deeper
Be ready to build a SHA-256 digest in two lines and say what each call returns: update() feeds bytes, digest() gives raw bytes, hexdigest() gives the hex string. Remember that a str must be encoded first.
Explain the mechanics: the object holds running state, chunk boundaries do not affect the result, reading a digest snapshots rather than finalizes, and digest_size fixes the output length regardless of input size.
Show where the incremental form earns its keep in production — streaming input you never buffer, running checkpoints, copy() for a shared prefix — and be clear that an unkeyed digest proves integrity against accidents, not against an attacker.
Own the standard: which digest the organisation uses for content addressing, whether digests are stored with their algorithm name so they can be migrated, and what it costs to rehash an existing corpus when that choice changes.
### A hash object is a state machine, not a function `hashlib` gives you one constructor per algorithm — `hashlib.sha256()`, `hashlib.sha512()`, `hashlib.blake2b()` — plus a lookup-by-name constructor, `hashlib.new("sha256")`, for when the algorithm arrives as configuration. All of them return the same kind of object: a mutable accumulator holding the digest's internal state. The convenience form passes the whole message to the constructor: ```python import hashlib hashlib.sha256(b"lat,lon\n51.5,-0.12\n").hexdigest() ``` The incremental form builds the same state in pieces: ```python h = hashlib.sha256() h.update(b"lat,lon\n") h.update(b"51.5,-0.12\n") h.hexdigest() ``` Both produce the identical digest, because the algorithm processes a byte stream and does not care where your chunk boundaries fell. That property is the whole point of `update()`: a digest over a 4 GB export, a socket, or a batch of records arriving one at a time never requires the full message in memory. What it does *not* mean is that the chunks are independent — the state carries forward, so the order of `update()` calls is part of the input. ### digest() versus hexdigest() `digest()` returns `bytes` of exactly `digest_size` bytes: 32 for SHA-256, 64 for SHA-512, 20 for SHA-1. `hexdigest()` returns a `str` of `2 * digest_size` lowercase hex characters — the same value, re-encoded for anywhere bytes are inconvenient: a log line, a filename, a JSON field, a URL. Neither is "more secure"; they are two renderings of one number. Choose `digest()` when the value goes back into binary machinery (a MAC comparison, a fixed-width column) and `hexdigest()` when a human or a text protocol will see it. The critical property for beginners: **calling either one does not finalize or reset the object.** Internally CPython snapshots the state and finishes a copy, so the accumulator survives untouched. This is legal and gives a running digest per line: ```python h = hashlib.sha256() for row in (b"a\n", b"b\n"): h.update(row) print(h.hexdigest()) ``` There is no `reset()` — to start over, build a new object. That asymmetry trips people who expect a stream API. ### Bytes only Hash functions are defined over octets, and Python refuses to guess an encoding for you: `hashlib.sha256("abc")` raises `TypeError: Strings must be encoded before hashing`. Any bytes-like object works — `bytes`, `bytearray`, a `memoryview` over a buffer — which is what makes zero-copy slicing of a read buffer possible. ### The useful extras Three attributes are worth knowing. `digest_size` is the output length in bytes; `block_size` is the algorithm's internal block length (64 for SHA-256), which matters when keying a digest; and `name` is the lowercase algorithm string, so a value that arrived through `hashlib.new()` can identify itself downstream when you store the digest alongside its algorithm. The last method is `copy()`. It clones the accumulator's state, so a long shared prefix is hashed once: ```python base = hashlib.sha256(b"a very long shared header...") for suffix in (b"-1", b"-2"): h = base.copy() h.update(suffix) ``` Without `copy()` you would re-hash the header per item. With it, each variant costs only its own tail. This is also the trick that makes a running checkpoint digest cheap: copy, finish the copy, keep feeding the original. ### What this cycle is and is not for The digest tells you two byte strings are the same (or, given a strong algorithm, that they are almost certainly not). It carries no key, so anyone can recompute it — a digest alone proves integrity against accidents, not against an attacker who can also rewrite the digest. It is also not a password store: a fast digest is fast for the attacker too, and both keyed digests and password hashing are separate APIs with their own rules. For everyday work — content addressing, dedupe keys, cache keys, "did this file change" — the update/digest cycle over a modern algorithm such as SHA-256 or BLAKE2 is exactly the right tool. ### Two mistakes that survive review The first is comparing across renderings. `h.hexdigest() == stored_bytes` is always `False`, because a `str` never equals a `bytes` object in Python and no exception warns you — the comparison simply reports "different" for every input. Decide once whether a stored digest is hex text or raw bytes, and convert at the boundary rather than at the comparison. The second is truncation done casually. Taking the first eight hex characters of a SHA-256 digest is fine as a log-friendly label and is not fine as an identity: 32 bits collide by birthday at roughly sixty-five thousand items. When you genuinely want a short fingerprint, ask the algorithm for one — `hashlib.blake2b(data, digest_size=16)` produces a proper 16-byte digest rather than a slice of a longer one — and never shorten a value that anything treats as unique.
- Does calling hexdigest() finalize the object so further update() calls fail?No. The implementation finishes a copy of the internal state, so the object is untouched and you may keep calling update() afterwards. That is what makes a running per-chunk digest possible. There is no reset() counterpart, though: to hash a fresh message you construct a new object.
- What is the difference between hashlib.sha256() and hashlib.new("sha256")?Nothing in the result — both return a SHA-256 hash object. The named constructors are direct module attributes and read better in fixed code; hashlib.new() takes the algorithm as a string, so it is the one to use when the algorithm comes from configuration or from a stored record, and it raises ValueError for a name this build does not support.
- Why does hashlib.sha256("abc") raise TypeError instead of encoding the text?Hash functions are defined over bytes, and the digest of a str depends entirely on which encoding you pick — UTF-8 and Latin-1 give different digests for any non-ASCII character. Python refuses to choose silently, so you must call .encode() with an encoding your whole system agrees on.
saying these in an interview costs you the question
- Thinks hexdigest() finalizes or resets the hash object
- Believes chunked update() calls give a different digest than one call
- Says digest() and hexdigest() are different algorithms or strengths
- Passes a str and expects automatic UTF-8 encoding
- Assumes there is a reset() method to reuse the object
- Treats a bare digest as proof against a tampering attacker