Why does printing a list of your objects show `__repr__` output instead of `__str__`?

This trips people up because the fallback they just learned appears to stop working. It does not — the object never gets asked for its `__str__` in the first place. ## What actually happens 1. `print(items)` evaluates `str(items)`, where `items` is the list. 2. `list` defines no `__str__`, so it inherits `object.__str__`, which delegates to `list.__repr__`. You can check this directly: `list.__str__ is object.__str__` is `True`, and so is the same expression for `tuple` and `dict`. 3. `list.__repr__` then walks the elements and calls `repr()` on each one, joining the results with `, ` inside square brackets. Your element's `__str__` is never consulted. `str(items)` and `repr(items)` therefore produce identical text for a list — a small fact that surprises people and is worth checking in a REPL once. ## Why the containers chose repr A container's text is a nested structure, and nested text has to be readable without ambiguity. Consider `['a', 1]`. - With `repr()` on the elements you get `['a', 1]`, and you can see that the first item is a string and the second an integer. - With `str()` you would get `[a, 1]`, where `a` might be the string `'a'`, a name, or an object whose `__str__` happened to return `a`. The moment elements can be strings, the `str()` rendering becomes lossy. The same reasoning applies to a dict, which reprs both keys and values, which is why `{'a': 'b'}` shows quotes on both sides. ## The knock-on effects Because reprs are what containers show, a missing `__repr__` degrades every place a collection is displayed: - a printed list, - a dict of objects in a log line, - an argument tuple inside an exception message, - a debugger's variables pane, - the value shown when a test assertion over a list fails. All of them collapse into indistinguishable `<Track object at 0x10a2f1c30>` entries. This is the single most common practical reason to write `__repr__` first: the payoff shows up in tooling you did not write. ## The fixes, in the right order 1. The real fix is to give the element class a `__repr__` that identifies the instance — `<Track 'audio-0'>` or `Track(name='audio-0')`. Adding a `__str__` to the element class does nothing for the list, because nothing on that path calls it. 2. If you genuinely need the readable form for each element in output, build the string explicitly: `", ".join(str(t) for t in items)`, or a comprehension of f-strings. Do not try to subclass `list` to change how elements are rendered; the element type is the one carrying the wrong information, and a container subclass that reprs its items differently from every other container is a trap for the next reader. ## Related surfaces worth knowing - The `pprint` module builds its output from `repr()` too, so pretty-printing a nested structure inherits the same rule. - `%`-formatting a container with `%s` gives the same text as `str()` on it, which — as above — is the repr rendering of the items. - And an f-string with no conversion, `f"{items}"`, routes through `__format__`, whose inherited implementation returns `str(items)`: again the item reprs. ## How to answer this in an interview 1. State the mechanism first: `print` calls `str` on the container, the container's text is built from `repr()` of each element, so element `__str__` is bypassed. 2. Then give the reason: unambiguous, nestable output. 3. Then give the fix: define `__repr__` on the element class, or format the elements explicitly. Candidates who say "lists call `__repr__` because Python is weird" have memorised the symptom; candidates who mention the quoting of nested strings have understood why the rule exists. ## Why `str` itself is the exception that proves the rule Of the built-in types, `str` is the one where `str()` and `repr()` genuinely differ: `str('a')` is `a`, while `repr('a')` is `'a'` with quotes. That single difference is the whole reason containers chose repr. Rendering `['a', 1]` with element `str()` would give `[a, 1]`, in which the string and the integer are indistinguishable, and a value containing a comma or a bracket would silently corrupt the shape of the output. Rendering with `repr()` keeps the text parseable by eye and, for simple structures, by `eval` too. Sets, tuples, nested lists and dicts all follow the same rule, all the way down, so a deeply nested structure prints as one consistent, unambiguous expression rather than a mixture of two conventions.