Why does enum.Flag raise on an int carrying bits no member names, while enum.IntFlag keeps them?

## The problem the boundary solves A flag enum names some bits. A value handed to it — from a database column, a config file, a message on a queue — may have bits it does not name. Before Python 3.11 the handling of that case was ad hoc and differed between `enum.Flag` and `enum.IntFlag`. 3.11 gave it a name: `enum.FlagBoundary`, an enum of four policies chosen per class with a `boundary=` class keyword. ```python from enum import Flag, IntFlag, CONFORM, EJECT, KEEP, auto class Perm(Flag): # boundary defaults to STRICT READ = auto() # 1 WRITE = auto() # 2 EXEC = auto() # 4 ``` **`STRICT`** — the default for `Flag`. Any bit outside the named set is an error: ```python Perm(8) # ValueError: <flag 'Perm'> invalid value 8 # given 0b0 1000 # allowed 0b0 0111 ``` The message prints the given and allowed bit patterns, which makes it one of the more helpful errors in the stdlib. **`KEEP`** — the default for `IntFlag`. The value is accepted whole and the unnamed bits are retained: ```python class IPerm(IntFlag): READ = auto() WRITE = auto() v = IPerm(9) v # <IPerm.READ|8: 9> list(v) # [<IPerm.READ: 1>] - the 8 is invisible here v.value # 9 - but it round-trips ``` **`CONFORM`** — unknown bits are stripped and a valid member is returned: with only `A = 1` and `B = 2` defined, `Cfg(7)` yields `<Cfg.A|B: 3>`. **`EJECT`** — the value leaves the enum entirely: `Cfg2(7)` returns the plain `int` `7`, and `type()` of it really is `int`. Anything downstream that assumed it had a flag member now has a number, which is why this is the rarest choice. ## Why `IntFlag` is lenient by design `IntFlag` exists for values that come from outside Python — an OS bitmask, a protocol field, a legacy column. In that world the process does not own the bit vocabulary and cannot assume it is complete, so refusing an unknown bit would break a program that has no business caring about it. `KEEP` also means a value read and written back is unchanged, which is the correct default for a pass-through. Plain `Flag` is for vocabularies the program *does* own, and there an unknown bit is a bug worth surfacing immediately. ## The production shape of this Consider a fraud-scoring service that stores per-rule toggles as one integer column. An 11-person team ships a new rule and adds a fourth flag; that deployment starts writing values with the new bit set. Any instance still running the previous code now reads those rows. With a plain `Flag`, the read raises `ValueError` — but only for the rows written since the new deployment, so it presents as a partial, data-dependent failure that looks intermittent from the outside and disappears entirely on a fixture-based test suite. That is loud in the right way, provided someone can act on it. With `IntFlag` under `KEEP`, nothing raises, the extra bit round-trips safely, and the only symptom is that a screen listing active rules never mentions the fourth one — because iteration yields named members only. Neither behaviour is wrong; shipping without deciding which one you want is. The decisions worth stating in an interview: * **Choose the boundary deliberately** and write it down: `class Perm(Flag, boundary=KEEP)` is one keyword and it documents the intent. * **Never let `CONFORM` near a permission or a deny bit.** Silently discarding a bit that meant "this rule is disabled" is a security-shaped failure, and it leaves no trace in the value. * **Version the vocabulary if the ints are persisted.** Reserved bits, a schema version alongside the value, or a rule that flags are only ever appended and never renumbered. * **Validate at the edge.** Convert the integer to a member once, at the boundary of the system, where a `ValueError` can be turned into a real error response — not deep inside a request handler. * **Test the unknown-bit path**, because normal fixtures never produce one; construct a value with a bit above the highest named member and assert on the behaviour you chose. ## Two details that catch people Iteration yields named members only, but `len()` counts the bits that are set — so under `KEEP` a value can report `len()` of 2 while iterating it produces exactly one member. The extra bit is present in `value`, in `len()` and in the `repr` (which shows it as a bare number, `<IPerm.READ|8: 9>`), and absent from every listing built by iterating. And the boundary applies to *construction*, not to the operators: combining two valid members can never produce an out-of-range value, so the check only fires where a raw value enters the enum. ## Version notes `enum.FlagBoundary` with `STRICT`, `CONFORM`, `EJECT` and `KEEP`, the `boundary=` keyword, and the current defaults (`STRICT` for `Flag`, `KEEP` for `IntFlag`) all arrived in Python 3.11 and are unchanged on 3.14.