What does operator.itemgetter(2, 0) return when called on a sequence?

`operator.itemgetter` is a small factory in the standard library's `operator` module. You call it with one or more lookup keys and it hands back a **callable object** that, when later applied to an operand, performs those lookups. Two facts about that sentence carry almost every interview answer on this: - the lookups are described up front but **performed later**, and - the number of keys you pass changes the **shape of the result**. ## The construction step stores, it does not fetch `getter = itemgetter(2, 0)` touches no data. There is no sequence in scope yet; all the object holds is the tuple of keys `(2, 0)`. The work happens on `getter(row)`, and it happens through the operand's `__getitem__` — `itemgetter` performs an ordinary subscription, exactly what `row[2]` compiles to. Nothing is cached between calls, so the same getter can be reused across thousands of different operands. ## One key returns a bare value; several return a tuple - `itemgetter(2)(row)` evaluates to `row[2]` — the raw item, not `(row[2],)`. - Add a second key and the return type changes: `itemgetter(2, 0)(row)` is `(row[2], row[0])`. This asymmetry is the single most common stumble, because code written against the one-key form breaks the moment somebody adds a second field. The order is **positional, as written**: `itemgetter(2, 0)` puts index 2 first, and it will not reorder the pair for you. Calling `itemgetter()` with no keys at all is an error — it raises `TypeError`. ## Any subscriptable operand works Because the mechanism is just `__getitem__`, the keys need not be integers. - On a dict, `itemgetter('plan')` fetches the value under the key `'plan'`; - on a list or tuple you can use negative indices, so `itemgetter(-1)` reads the last element; - and you may pass a `slice` object, so `itemgetter(slice(1, 3))([10, 20, 30, 40])` returns `[20, 30]`. Mixing kinds in one getter is legal as long as the operand supports each key — for a dict, `itemgetter('id', 'amount')` returns both values as a tuple. What does **not** work is reaching for an attribute: `itemgetter('plan')` applied to an object that merely has a `.plan` attribute raises `TypeError`, because the object is not subscriptable. That job belongs to `operator.attrgetter`. The trap version of this is a `namedtuple`, which looks like it should accept `itemgetter('amount')` — it does not, because tuple indexing demands an integer; you index a namedtuple by position or fetch the field by attribute. ## Errors surface at call time and belong to the operand - A missing integer index on a list raises `IndexError`; - a missing dict key raises `KeyError`; - an unsupported key type raises `TypeError`. `itemgetter` adds no default and no swallowing — there is no third argument the way `getattr` has one. If some rows may be short or some dicts may be missing a key, you must handle that yourself, and that is often the honest reason to write an ordinary function instead. ## Why the module exists at all Everything above can be written as an inline function of one argument, so `itemgetter` has to earn its place. It does so in three ways. 1. It is **implemented in C** in CPython, so a call does not push a Python frame — over a long loop of lookups that is a real, if modest, saving. 2. It is **declarative**: `itemgetter(2, 0)` states which fields, in which order, with nothing else hiding in the body. 3. And the resulting object is an instance of a real, importable type that knows how to rebuild itself, so it can be **serialized and shipped elsewhere**, which an anonymous inline function cannot. The place you meet it most is the `key=` argument of `sorted`, `min`, `max` and `heapq` helpers, where the multi-key form gives you a compound ordering key in one expression. ## The object is stateless, and that is the point A getter holds nothing but its keys, so it is safe to build once at module level and reuse from anywhere, including from several threads, and building one per element in a loop is pure waste. Because the result of the multi-key form is an ordinary tuple: - it unpacks like one — `ident, amount = itemgetter(0, 2)(row)` reads cleanly — - and it compares like one, element by element from the left, which is what makes the multi-key form useful for ordering records at all. Two getters built from the same keys are distinct objects and do not compare equal, so treat them as opaque callables rather than as values to test for equality. ## When not to use it `itemgetter` can only fetch; it cannot compute. The moment you need `row[2] * 1.2`, a `.lower()` on the fetched value, or a fallback for a missing field, you are past what it expresses and should write a named function — readability wins, and the C-level saving was never the point.