What does functools.partial return, and how are its stored arguments merged at call time?

## What it actually builds `functools.partial(func, *args, **keywords)` is an application of arguments that has been *deferred*. It does not invoke `func`, it does not mutate `func`, and it does not hand you back a function. It returns an instance of the `functools.partial` type, which stores exactly three things and is itself callable: * `.func` — the callable that will eventually run * `.args` — a tuple of the positional arguments you pre-bound * `.keywords` — a dict of the keyword arguments you pre-bound Those three attributes are the whole object. Anything you can predict about a partial's behaviour follows from how they are combined at call time. ## The merge rule When you call the partial with `*fargs, **fkeywords`, it effectively runs: ```python func(*stored_args, *fargs, **{**stored_keywords, **fkeywords}) ``` Read that carefully, because the two halves behave differently: **Positional arguments are prepended.** The stored tuple always comes first, and the call's positionals follow. That means a partial can only freeze a *leading prefix* of the parameter list. Given `def divide(a, b)`, `partial(divide, 1)` fixes `a`, and `half(4)` runs `divide(1, 4)`. There is no positional way to fix `b` and leave `a` open — to freeze a parameter that is not at the front, you must name it: `partial(divide, b=2)`. **Keyword arguments are merged, and the caller wins.** A pre-bound keyword is a *default*, not a lock. `report = partial(format_row, unit="mmol/L")` still lets `report(5.1, unit="mg/dL")` through, and the call's value replaces the stored one. This is deliberate and often useful, but it surprises people who expect pre-binding to be final. **Mixing the two can collide.** With `def divide(a, b)` and `p = partial(divide, 1)`, calling `p(a=9)` raises `TypeError: divide() got multiple values for argument 'a'` — the stored positional already filled `a`. Likewise, supplying more positionals than the signature accepts raises the ordinary "takes N positional arguments" `TypeError`. Nothing about a partial changes the underlying function's arity checking; the errors you get are the errors `func` itself would raise, because it *is* `func` raising them. ## It is an object, not a function This distinction shows up constantly in real code. A partial has no `__name__`, so `hasattr(p, "__name__")` is `False` and any framework, logger or dispatch table that identifies callbacks by `callback.__name__` raises `AttributeError` when you hand it one. Its `repr()` is `functools.partial(<function f at 0x...>, 1)`, which is genuinely informative in a traceback or a log line — you can see the target and the frozen arguments. `inspect.signature()` understands partials and reports the *remaining* parameters when the wrapped callable has an introspectable signature (it fails on builtins that expose none, exactly as it fails on those builtins directly). Because the state lives in plain attributes, a partial is transparent in a way a hand-written closure is not: given a registry of callbacks you can print `cb.func` and `cb.keywords` and see the configuration each one carries. That introspectability, not brevity, is the main reason to reach for it. ## Composition and nesting Partials compose: passing a partial as the `func` of another partial is allowed, and the argument prefixes apply in order, outermost binding first. They also drop naturally into any API that takes a callable — `sorted(rows, key=partial(...))`, `map(...)`, a `dict` of handlers, a scheduler's callback slot, an `iter(callable, sentinel)` loop. ## The mental model to keep Say it back as one sentence: *a partial stores a callable plus a prefix of positionals and a dict of keyword defaults, and calling it concatenates.* Concatenation explains the prefix restriction; dict merging with the caller on the right explains the override. Every other behaviour — the collision `TypeError`, the missing `__name__`, the readable `repr` — falls out of "it is an object holding three fields", not out of any special interpreter support.