What does enum.ReprEnum change about how enum.IntEnum members print?

### The problem ReprEnum was created to solve Two audiences read an enum member as text. A human reading a traceback or a debugger wants `<Priority.HIGH: 3>` - the class, the name, the value. Code that is formatting a value for a protocol wants `3`. Before **Python 3.11** the mixed-in kinds served neither audience consistently: `str(Priority.HIGH)` gave `"Priority.HIGH"` while `format(Priority.HIGH)` - and therefore an f-string - already gave `"3"`. The same member rendered two different ways depending on which formatting route you took. `enum.ReprEnum`, added in 3.11, resolves that. It is a base class that means: **keep Enum's `__repr__`, but let the mixed-in data type supply `__str__` and `__format__`.** The name is counter-intuitive - it does not change `__repr__`, it *preserves* it while surrendering everything else to the data type. ### What that produces on 3.14 `enum.IntEnum`, `enum.StrEnum` and `enum.IntFlag` all derive from `ReprEnum`, so for `class Priority(IntEnum): HIGH = 3`: ``` str(Priority.HIGH) -> '3' f"{Priority.HIGH}" -> '3' f"{Priority.HIGH:03d}" -> '003' # int.__format__ honours the int spec "%s" % Priority.HIGH -> '3' repr(Priority.HIGH) -> '<Priority.HIGH: 3>' Priority.HIGH.name -> 'HIGH' ``` Contrast the hand-rolled mixin `class Legacy(int, Enum): HIGH = 3`, which does **not** inherit from `ReprEnum`: its equality and arithmetic are identical to `IntEnum`'s, but `str(Legacy.HIGH)` and `f"{Legacy.HIGH}"` are both `"Legacy.HIGH"`. Two classes with the same values and the same comparison semantics, printing completely differently. That is the distinction the question is really about, and it is why "just use `(int, Enum)`" is not interchangeable advice. You can use the base directly for other data types: `class Ratio(float, ReprEnum): HALF = 0.5` gives `str(Ratio.HALF) == "0.5"` with `repr()` still `<Ratio.HALF: 0.5>`. `ReprEnum` requires a data-type mixin; on its own it has nothing to borrow `__str__` from. For completeness, a plain `enum.Enum` is unaffected by any of this: `str(Color.RED)` and `f"{Color.RED}"` are both `"Color.RED"` on 3.14, and its `repr()` is `<Color.RED: 1>`. ### Why this is a production question, not trivia The rendering is invisible until something interpolates a member into a string, and then it is everywhere: log messages built with `%s` or an f-string, metric and span labels, cache keys, URL path segments, filenames, error text shown to a user. A service that upgrades from 3.10 to 3.11 sees every one of those flip from `Priority.HIGH` to `3` at once - no exception, no test failure unless a test asserts on the text, just a different string in production. If any of those strings is parsed downstream, keyed on, or grouped by a dashboard, the change is a real incident: the dashboard's series splits, the cache misses on every entry, the alert rule matching `priority=HIGH` stops matching. Landing that mid-way through a three-week release train, with the interpreter bump bundled among other changes, makes it genuinely hard to attribute. ### The habit that makes it a non-issue Never let the human-readable form of an enum be an accident of `str()`. Where a label is wanted, ask for it: `member.name` for the identifier, an explicit mapping or a `label` property for user-facing text, and `member.value` where the raw datum belongs. Reserve `str()` and bare f-string interpolation for cases where you actively want the mixed-in type's rendering - which, for an `IntEnum` on the wire, is often exactly right. Before an interpreter upgrade, the concrete audit is to search for enum members inside f-strings, `%`-format arguments, `str()` calls and `logging` arguments, and to check whether any downstream consumer parses or groups by the result. It is a small grep, and it is the difference between a noticed change and a silent one.