Why does `str(exc)` on a caught `NameError` omit the "Did you mean" hint the console prints?

Type `print(lenghth)` at a Python prompt after binding `lenght` and you get: ``` NameError: name 'lenghth' is not defined. Did you mean: 'lenght'? ``` Catch the same error and print `str(exc)` and you get `name 'lenghth' is not defined` - no hint. That difference is not a bug, and understanding it explains a whole family of "my logs are worse than my terminal" complaints. ### Two different strings An exception instance holds an argument tuple, and `str()` on it renders that. For `NameError` the interpreter fills it in at raise time with the plain sentence. The suggestion is produced **later, by the code that renders a traceback**, and only if a traceback is actually rendered. Since most exceptions in a running system are caught and handled, doing the search at raise time would tax every handled error to benefit the small minority that get printed. Deferring it is the right design, and it has the consequence above. ### What the search actually looks at The exception object carries the failing name, which is why a suggestion is possible at all: the renderer does not have to re-parse source. It then needs candidates, and where it gets them depends on the exception: - **`NameError`** - the names visible in the frame that raised: its locals, its globals, and the builtins. - **`AttributeError`** - the attribute names of the object that was accessed, essentially what `dir()` would report. - **`ImportError`** from a `from ... import ...` statement - the names the module actually exports. Each candidate is compared to the failing name with a cheap edit-distance style similarity, and the best match is offered only if it is close enough. The search is deliberately bounded: when the candidate set is very large, or the names are long, CPython skips the search rather than spend real time inside error display. So the absence of a suggestion tells you nothing about whether a near-miss name exists - a typo inside a module with thousands of globals may simply not be searched. This also explains a gap people notice: an attribute served dynamically by a `__getattr__` implementation, which never appears in `dir()`, cannot be suggested. The renderer can only propose names it can enumerate. ### The `self` case **Python 3.12** added a suggestion that reads differently from the rest. Inside a method, if you write `duration` where you meant `self.duration`, the `NameError` display says `Did you mean: 'self.duration'?`. It is the same machinery, extended with the instance's attributes as candidates when the failing frame belongs to a method. It catches one of the most common Python-in-a-class mistakes, and it is worth knowing it exists because it is the kind of hint an engineer reading only log messages will never see. ### Why this matters beyond the REPL A great deal of production Python logs errors as a single formatted message. Written that way, three things the interpreter computed for you are discarded: the caret anchor showing which sub-expression failed, the chained context of a `raise ... from ...`, and this suggestion. The fix is not clever - render the exception rather than stringifying it, and send the rendered text to the log - but teams routinely discover it only after an incident where the terminal reproduction was obviously diagnosable and the production log was not. There is a second, quieter consequence. Because the suggestion is generated at display time from live namespaces, the text of a printed error can differ between two runs of the same code - a name defined by one code path and not another changes the candidate set. That is fine for a human reading a terminal, and mildly annoying if you are grouping errors by exact message in an aggregator: the same defect can produce two message strings. Group on the exception type and the code location, not on the rendered sentence. ### Version summary Suggestions for `NameError` and `AttributeError` arrived in **Python 3.10**. **Python 3.12** extended them to `from ... import ...` names and added the `self.attr` form. Nothing about them is stored in the exception message in any of these versions, which is the part that stays true across releases.