How do you keep an API key field out of a Python dataclass's repr()?

## Why a dataclass is the risky shape A plain Python class you write by hand inherits the default `object.__repr__`, which prints only the type name and an address. It leaks nothing. The moment you decorate the same class with `@dataclass`, the decorator generates a `__repr__` that renders **every** field, in declaration order, with each value's own `repr`. That is a genuine convenience for debugging, and it is why credentials leak from dataclasses more often than from hand-written classes: the danger arrives together with the convenience, silently, at the moment someone adds the decorator. The leak surface is wider than `print(obj)`. The generated representation is what shows up in an f-string with the `!r` conversion, in the value column of a debugger, in the `repr` of any container that holds the object (a list of client configs, a dict of tenants), in a crash reporter's frame-locals rendering, and in `%s`-style formatting, because when a class defines no `__str__` at all, `str()` falls back to `__repr__`. ## The mechanism Each field carries a `repr` flag that defaults to true. `dataclasses.field(repr=False)` sets it false for one attribute, and the generated `__repr__` simply omits that attribute from the rendered text. Nothing else changes: the field is still a normal `__init__` parameter, still compared by `__eq__` unless you also pass `compare=False`, still present in `__dict__`. ```python from dataclasses import dataclass, field @dataclass class ExchangeCreds: account_id: str api_key: str = field(repr=False) ``` Note that `field(repr=False)` supplies no default value, so it does not force the field to become optional and does not disturb the usual "fields without defaults come first" rule. There is a blunter variant: `@dataclass(repr=False)` at class level suppresses generation of `__repr__` entirely, leaving the safe `object` default. That is a reasonable choice for a class that is all secret and nothing else, at the cost of losing debuggability for its harmless fields. ## What repr=False does not do This is where the interview usually goes, and the honest answer is that the flag governs one method and only that method. `dataclasses.asdict(obj)` walks every field regardless of its `repr` flag and returns them all in a dict (recursing into nested dataclasses and deep-copying the leaves), so the secret is right there and will be in whatever JSON that dict becomes. `vars(obj)` and `obj.__dict__` expose it directly. `pickle` serializes the instance state, secret included. `dataclasses.replace()` reads it. Any code doing `obj.api_key` obviously reads it. And a structured logging library that serializes an object's attributes rather than calling `repr` on it is unaffected by the flag. So `repr=False` is a good, cheap guard against the accidental *debug-print* class of leak. It is not a security boundary, and describing it as one in an interview is a red flag of its own. ## The stronger pattern: make the value itself unprintable When a credential is passed around - into a client object, into a retry wrapper, into a task payload - masking it at one dataclass only protects that one dataclass. The pattern that scales is to give the secret its own tiny type whose `__repr__` and `__str__` both return a fixed mask, and which surrenders the plaintext only through a named method: ```python class Secret: __slots__ = ("_value",) def __init__(self, value): self._value = value def reveal(self): return self._value def __repr__(self): return "Secret(***)" __str__ = __repr__ ``` Now the masking travels with the value. It survives being put in a list, in a dict, in a dataclass someone writes next year, and in `asdict()` output, because what lands in the dict is the `Secret` object, not the string. The explicit `.reveal()` call is also a grep target: every place the plaintext is actually needed is now visible in a code search and in review, which is a much better control than remembering a flag on every declaration. The usual caveat applies: `reveal()` returns a `str`, and a `str` cannot be erased, so the wrapper narrows *where* the plaintext exists rather than removing it from the process. ## What to check for in review Three habits catch nearly all of this class of bug. Prefer a dedicated secret type over a bare `str` in any structure that will be printed. Where a bare `str` is unavoidable, mark it `field(repr=False)` at declaration time rather than after an incident. And write one small test that asserts the token's characters do not appear in `repr()` of the config object, so a future field added to the same dataclass cannot quietly reintroduce the leak.