What is the difference between an iterable and an iterator in Python?

### Two cooperating roles, one protocol Python splits "something you can walk through" into two objects that play different roles. An **iterable** is an object that can *produce* a walker. It implements `__iter__`, and the builtin `iter(x)` is what calls it. A list, a tuple, a `str`, a `set`, a `dict`, a `range` object and the views returned by `dict.keys()` are all iterables. An **iterator** is the walker itself. It implements `__next__`, which hands back the next item on each call and raises `StopIteration` once there is nothing left, and it also implements `__iter__` — which returns `self`. That last clause is the entire distinction in one line: `iter(container)` gives you a **new** object; `iter(iterator)` gives you **the same** object back. ### Why the split exists Because a position is state, and state has to live somewhere. A list holds elements; it does not hold "where you are". If a list were its own cursor, then two walks over the same list — a nested loop, a comprehension inside a function called from a loop, a `sum()` followed by a `for` — would fight over one shared position. By making `__iter__` mint a fresh cursor each time, Python lets any number of independent walks proceed over one container at once. Each cursor is cheap: for a list it is little more than a reference to the list plus an integer index. The consequence runs the other way too. When items are produced on demand rather than stored — a generator object, a file being read line by line, a stream arriving over a socket — there is no container behind the walk and no position to rewind to. Such an object *is* the cursor, so its `__iter__` returns `self`, and once consumed it is finished for good. ### Why an iterator must also be an iterable Every construct that consumes items calls `iter()` on its argument first: `for`, comprehensions, `sum()`, `max()`, `min()`, `sorted()`, `list()`, tuple unpacking. If an iterator did not answer that call, none of them could take one directly. Returning `self` makes the call a no-op that costs nothing and, crucially, preserves the position — which is why feeding a half-consumed iterator to a `for` loop **resumes** where it stopped rather than starting over. So the relationship is one-directional: every iterator is an iterable, but most iterables are not iterators. ### Telling them apart at runtime Three checks, in increasing formality: - `iter(x) is x` — `True` only for an iterator. The most direct test, and the one worth remembering. - `hasattr(x, "__next__")` — an iterator defines it; a plain container does not. - `isinstance(x, collections.abc.Iterator)` versus `isinstance(x, collections.abc.Iterable)` — these abstract base classes check structurally for the required methods rather than demanding registration, so they answer correctly for types they have never seen. Note that the `Iterable` check is `True` for both roles; only the `Iterator` check separates them. ```python from collections.abc import Iterable, Iterator nums = [1, 2, 3] cursor = iter(nums) print(isinstance(nums, Iterator), isinstance(cursor, Iterator)) # False True ``` Iterables that are *not* iterators: `list`, `tuple`, `str`, `bytes`, `set`, `frozenset`, `dict` and its views, `range`. Objects that *are* iterators: generator objects, the file object `open()` returns, the result of `enumerate()`, and nearly everything the `itertools` module produces. ### What the protocol deliberately does not promise Iterability is the weakest of Python's data contracts. It says nothing about length, indexing, ordering or repeatability. `len()` does not work on a generator object; `x[3]` does not work on an iterator; and nothing in the protocol lets you ask an iterator whether it has already been consumed — an exhausted one is indistinguishable from an empty source. A sequence adds the stronger promises: integer indexing, `__len__`, slicing. ### Why an interviewer asks it This is not vocabulary trivia; it is the root of a whole family of production bugs. A function that returns an iterator hands its caller a **one-shot value**. If the caller logs it, then loops over it; validates it, then processes it; or passes it to two helpers, the second read sees nothing and raises no error. Deciding whether a public function returns a lazy iterator or a materialized container is therefore a real API design choice: the iterator buys streaming and bounded memory, and it charges the caller with a single-consumption rule that the type system will not enforce for them. Candidates who can state the two definitions, name the `self`-return, and then explain the consequence for calling code are demonstrating three distinct levels of understanding in one answer.