When is str.translate with str.maketrans better than chained str.replace calls?

### What `translate` actually does `str.translate(table)` iterates the string once, and for each character looks up its **ordinal** (its Unicode code point, as `ord` would give it) in `table`. The lookup can produce: - a **string** — substituted in place of the character (it may be longer than one character, or empty), - an **integer** — treated as the code point of the replacement character, - `None` — the character is deleted, - nothing at all (a `KeyError` from the mapping) — the character is passed through unchanged. The table is any object supporting `__getitem__` on an integer key, which is why a plain `dict` works. `str.maketrans` is the static helper that builds one correctly, in three forms: - `str.maketrans(mapping)` — a dict whose keys are single-character strings or ordinals, and whose values are strings, ordinals or `None`. - `str.maketrans(from_chars, to_chars)` — two equal-length strings, mapped position by position. - `str.maketrans(from_chars, to_chars, delete_chars)` — as above, plus a third string of characters to drop entirely. ### Property one: replacements never cascade This is the correctness argument, and it is the one worth having ready. ```python s = 'a-b' s.replace('a', 'b').replace('b', 'c') # 'c-c' s.translate(str.maketrans('ab', 'bc')) # 'b-c' ``` The chained version is wrong for the intended mapping because the second `replace` cannot tell an original `b` from the `b` the first call just produced. Every chain of `replace` calls whose replacement alphabet overlaps its search alphabet carries this bug. `translate` is immune by construction: each *input* character is examined exactly once, and whatever it becomes is never re-examined. The failure is order-dependent, which makes it nasty. Reorder the two calls and the output changes; the version that happens to be correct for today's inputs breaks when a new character is added to the mapping. It is the kind of defect that reaches a large regression pack — a 340-case sweep over records from an inventory sync between two systems, say — and passes every case, because none of the fixtures happens to contain a character that appears on both sides of the mapping. It only fails when a feed arrives whose text carries a character an earlier rule introduces. ### Property two: one pass, and a table you build once A chain of N `replace` calls performs N full scans and builds N intermediate strings, each of which is allocated and thrown away — `str` is immutable, so there is no in-place option. `translate` performs one scan and builds one result, and because the table is an ordinary object you can build it once at import time and reuse it for every record. In a normalisation step that runs over every row of a feed, that difference is the whole cost of the step. Do not oversell it as the headline, though: the correctness argument is the one an interviewer is really testing, and the performance claim only becomes material at volume. ### Deletion is the underrated form The three-argument form is the cleanest way to strip a set of characters from anywhere in a string — not just from the ends, which is what `strip` does: ```python drop = str.maketrans('', '', ' -_') 'SKU 1120-A_B'.translate(drop) # 'SKU1120AB' ``` That is the canonical way to canonicalise identifiers before comparing them, and it beats a chain of three `replace` calls on both counts above. Equivalently, a dict mapping each ordinal to `None` does the same job when you want to build the set programmatically. ### The limits `translate` is strictly **per character**. It cannot map a two-character sequence to something else, cannot do context-sensitive substitution, and cannot reorder. The moment your rule is about a *word* or a *sequence*, `str.replace` is the correct tool and the chain question becomes "in what order, and does the alphabet overlap?" — a question you answer by making the replacements disjoint, or by doing them in one pass some other way. `bytes` and `bytearray` have their own `translate` and `maketrans`, but the contract differs: the table is a 256-byte object mapping every possible byte value, and deletion is a separate `delete` argument rather than a `None` value. Do not carry the `str` mental model across unexamined — and never build a `str` table and hand it to a bytes method. ### Interview framing This is a differentiator rather than a gate: plenty of strong engineers have never needed `translate`. What earns credit is naming the cascading-replace hazard first and the single pass second, showing the deletion form, and knowing the boundary — per character only, so multi-character rules stay with `replace`.