How does functools.partialmethod differ from functools.partial in a class body?

## The problem partialmethod exists to solve Pre-binding arguments to a *function* and pre-binding arguments to a *method* are not the same operation, because a method call inserts the instance. `functools.partialmethod` is the class-body counterpart of `functools.partial`, and the whole of the difference is argument order. Write a class with a general worker method and two preconfigured entry points: ```python class Reader: def _read(self, encoding, path): ... read_utf8 = partialmethod(_read, "utf-8") ``` Accessing `reader.read_utf8` produces a callable that runs `_read(reader, "utf-8", path)`. The instance goes in first, exactly where the `self` parameter is, and the frozen arguments follow. That is what makes the result usable as a method: the underlying function's signature is untouched, and subclasses can override `_read` and have both entry points follow. ## What a plain partial does there instead Since Python 3.14, `functools.partial` is itself a method descriptor, so a partial stored in a class body is also bound on attribute access. But it binds by partial's *own* rule, which is to prepend the stored arguments — the instance ends up appended after them. With `broken = partial(_read, "utf-8")`, calling `reader.broken("rows.csv")` runs `_read("utf-8", reader, "rows.csv")`: the string lands in `self`, the instance lands in `encoding`, and you get either a bizarre `TypeError` or, worse, a call that quietly succeeds with nonsense in the wrong parameters. This is a genuinely new hazard. Before 3.14, a `partial` in a class body was a plain attribute with no descriptor behaviour: `reader.broken("rows.csv")` never received the instance at all and typically failed with a missing-argument `TypeError`. Python 3.13 shipped a `FutureWarning` on that access announcing the coming change and telling you to wrap the partial in `staticmethod()` if you wanted the old non-binding behaviour. Anyone maintaining a codebase across that boundary should treat a partial in a class body as a thing to look at, not a thing to skim. ## Practical guidance The rule reduces to a sentence: **`partialmethod` in a class body, `partial` everywhere else.** If a preconfigured callable is going to be reached as `obj.name(...)`, it must be a `partialmethod`. If it is a free function, a callback in a registry, a `key=` argument, or anything handed to a pool, it is a `partial`. A few consequences worth carrying: * **Naming still differs from a normal method.** A `partialmethod` is not a function object; the accessed attribute has no `__name__` of its own, so tooling that identifies methods by name may need `.func`. * **Introspection is retained.** Like a partial, a `partialmethod` keeps its target and frozen arguments as public state, so the class documents its own preconfigured entry points. * **A hand-written method is often simpler.** `def read_utf8(self, path): return self._read("utf-8", path)` is three more characters and reads better to most teams. `partialmethod` earns its place when you are generating a family of entry points programmatically, or when the frozen argument list is long enough that repeating it invites drift. * **Overriding still works normally.** Because both forms ultimately call a named method on the class, subclass overrides of the underlying method take effect through the preconfigured entry point. ## Answering it well An interviewer asking this is probing whether you understand the descriptor protocol well enough to predict where `self` goes, and whether you track version-sensitive behaviour. Lead with "both are descriptors now, they differ in where the instance is inserted", give the two argument orders explicitly, then note that `partial` only became a method descriptor in 3.14 and that 3.13 warned about it. That is the complete answer, and the version detail is what separates a rehearsed one from a current one.