Why does a traceback frame read '<lambda>', and what does PEP 8 advise about it?

## What the frame name comes from When CPython compiles a function it stores a name in the code object. A `def` stores the identifier you wrote. A lambda has no identifier to store, so the compiler stores the literal string `'<lambda>'`, and that string becomes the function's `__name__` and the last segment of its `__qualname__`. Every downstream consumer of a function's identity reads those attributes: the traceback formatter, `repr()` of the function, the function-name field of a standard logging record, profiler tables, and most monitoring agents that aggregate by frame. So a stack line such as `File "digest.py", line 41, in <lambda>` is not a bug and not a special error state — it is the only name that exists. The consequence is operational. Imagine a nightly email-digest sender that builds its per-recipient formatting rules as a dozen lambdas bound to a dozen names. When one of them raises on a malformed record, the on-call engineer's alert says `<lambda>` and a line number. If the file has been edited since the release that is running, even the line number lies. Every one of those frames would have carried a real, greppable name had the author typed `def`. ```python format_subject = lambda user: user["name"].title() def format_subject_def(user): return user["name"].title() print(format_subject.__name__) # <lambda> print(format_subject_def.__name__) # format_subject_def ``` ## What PEP 8 actually says The style guide's rule is narrow and worth quoting accurately: always use a `def` statement instead of an assignment statement that binds a lambda expression directly to an identifier. Its stated reason is that the `def` form is more useful for tracebacks and string representations, and that the assignment removes the sole benefit a lambda offers over a `def` — that it can be embedded inside a larger expression. Note the boundary. The rule is about `name = lambda ...`, not about lambdas in general. A lambda passed inline as a sorting key, a callback or a factory argument is exactly what the form is for, and PEP 8 has no objection to it. Linters ship a check for the assigned-lambda pattern, and it is one of the few style checks that is nearly always right, because the fix is mechanical and lossless. ## What else the assignment costs **Debugging.** Setting a breakpoint inside a one-line body is awkward, and stepping through it gives you no name to anchor on. A `def` body is a normal block with normal line boundaries. **Documentation and typing.** A lambda cannot hold a docstring and its parameters cannot be annotated, so a named lambda is invisible to a type checker's parameter-level checking and to any tooling that harvests docstrings. A `def` gets both for free. **Serialization.** The standard pickling protocol serialises a function by reference — module plus qualified name — and then verifies that looking that name up again yields the same object. `'<lambda>'` is not a resolvable name, so pickling a lambda fails. That turns into a real production failure the first time someone hands the callable to a worker process that requires a picklable payload, or tries to cache it. A `def` at module level pickles by reference without any of this. **Decoration.** Decorator syntax applies to a `def` or a `class`; decorating a named lambda means calling the decorator by hand around the assignment, which reads worse than the `def` would have. **Grep.** `def format_subject` is findable. `format_subject = lambda` is findable too, but the traceback that sent you looking said `<lambda>`, so you had nothing to grep for in the first place. ## Diagnosing it after the fact If you inherit a codebase full of named lambdas and a stack of `<lambda>` frames, the file and line in the traceback still locate the code; use them, then convert as you go rather than in one sweeping change. If you need to distinguish frames at runtime before converting, `__qualname__` at least tells you which enclosing function the lambda was defined in, which narrows a large module considerably. Some codebases reassign `__name__` on the function object after creating it — that fixes logging output but not the traceback, which reads the *code object's* name, so it is a half-measure that misleads the next reader. Convert to `def`. ## The judgement being tested This is a production-experience question. The junior answer is "PEP 8 says don't". The answer that lands names the mechanism (`__name__` is the literal `'<lambda>'` and every diagnostic reads it), names the concrete costs (tracebacks, logs, profiles, pickling, annotations, breakpoints), and draws the boundary correctly: the rule is about the *assignment*, and inline lambdas remain entirely idiomatic.