Why can reordering a dataclass's fields silently change what `case Batch(a, b)` binds?

Consider a search-index rebuilder that fans work out as small dataclass messages and dispatches them with `match`. At its peak of roughly 1,200 requests per minute the hot path is a handler that reads two fields off each batch. A later refactor reorders the dataclass's fields — perhaps to move a field with a `default_factory` after the required one, having already been bitten once by a mutable default — and every positional pattern in the dispatcher quietly changes meaning. ## Why it is silent `dataclasses.dataclass` builds `__match_args__` from the parameters of the `__init__` it generates: the fields, in declaration order. Reordering the fields reorders the tuple. A positional class pattern is rewritten at match time into keyword form using that tuple, so `case Batch(a, b)` becomes `case Batch(docs=a, shard=b)` where it used to be `case Batch(shard=a, docs=b)`. Nothing in that chain raises: * The pattern compiles — patterns are checked for syntax, not for the class's attribute layout. * The isinstance test still passes; it is the same class. * The arity check still passes; two names, two sub-patterns. The arity `TypeError` is the only automatic guard class patterns have, and a reorder does not trip it. * The captures still bind. `a` and `b` simply hold each other's values. What happens next depends entirely on the fields. If one is an `int` and the other a `list`, something downstream usually explodes — with a traceback pointing far away from the dispatcher. If both are integers, a shard id and a document count swap places and the rebuilder indexes into the wrong shard at full rate, with no error anywhere. That asymmetry is what makes the bug expensive: the harmless-looking version is the one that corrupts data. Two related timing traps are worth naming in the same breath. The arity `TypeError` that *does* exist fires only at match time and only after the isinstance gate passes, so a pattern with the wrong number of sub-patterns for an uncommon message class can sit in production for months before the first such message arrives. And a class with no `__match_args__` at all accepts zero positional sub-patterns, so converting an ordinary class to a dataclass silently *enables* positional patterns that previously raised — a change in the opposite direction, equally invisible in review. ## What actually defends against it **Prefer keyword sub-patterns.** `case Batch(shard=s, docs=d)` is immune: the attribute names are written at the match site, so a reorder cannot change what binds, and a rename fails loudly with a non-match you will see in tests. Reserve positional form for small value types where the ordering is self-evident and both the class and its patterns live close together — a two-field coordinate, a parsed token. Everything wider, or matched across module boundaries, should be keyword. **Pin the tuple when the class is a pattern target.** A `__match_args__` written in the class body is not overwritten by the decorator, so declaring it explicitly decouples the destructuring order from the field layout and puts the contract in one visible place. `match_args=False` is the other lever, when you want to forbid positional patterns entirely. **Assert it in a test.** A single `assert Batch.__match_args__ == ("shard", "docs")` turns a silent refactor into a failing build. It is one line, and it is the only check that runs at build time rather than at match time. **Do not expect a type checker to save you.** It will catch a swap when the bound names are then used incompatibly — passing a list where an integer is expected. It cannot help when both fields share a type, which is the dangerous case. ## The judgement being tested The interviewer is not really asking about `__match_args__`. They are asking whether you recognise that pattern matching introduces a *new consumer* of a class's field order, one that is not visible from the class definition and is not covered by the usual "the constructor signature is public" instinct. A dataclass's field order was previously a contract for positional construction, which most teams already avoid via keyword arguments; pattern matching quietly makes it a contract for destructuring as well, at every match site in the codebase. The mature stance is to say so out loud in the code: keyword sub-patterns by default, positional only where the ordering is part of the type's identity, and an explicit `__match_args__` on any class that other modules destructure. It costs nothing at runtime — the positional form is rewritten to keyword form anyway — and it removes an entire class of refactor hazard.