Exercises — Iterators — `__iter__`, `__next__`, StopIteration

The test: has __next__ ⇒ iterator (it's a tape player). has __iter__ returning an iterator ⇒ iterable (it's a bag). Both ⇒ both.

1. [1,2,3] — iterable only. A list has __iter__ but no __next__. Check: hasattr([], '__next__') is False.
2. iter([1,2,3]) — both. It is a list_iterator; it has __next__ (it's the tape player) and its __iter__ returns self.
3. range(5) — iterable only. range has __iter__ but no __next__; each iter(range(5)) gives a fresh range_iterator.
4. Countdown(3) — both. Its __iter__ returns self and it defines __next__, so the object is its own tape player.

The pattern: containers (list, range, dict) are iterable-only; the thing iter() returns is the iterator; a class whose __iter__ returns self is both.

Three values live in the list, so 3 successful presses.

next(it)   # 10   (1st press)
next(it)   # 20   (2nd press)
next(it)   # 30   (3rd press, last item)
next(it)   # raises StopIteration   (4th press → tape ended)

The iterator holds a position; each press advances it. Once position passes the last index, the "end of tape" click fires.

list(...) presses next until StopIteration.

Result: [3, 2, 1]. The exhaustion check runs first, so when current is 0 we stop before returning it. That is exactly why 0 never appears.

7
end
end

First press returns the only item 7. Every press after exhaustion would raise StopIteration, but the default 'end' catches it internally and returns 'end' instead. The iterator stays exhausted, so it keeps giving 'end' forever.

List version — 4 pairs. Each for calls iter(nums) and gets a separate tape player with its own position. The outer loop's player and the inner loop's player advance independently over the same bag. Look at the figure below: two arrows (orange = outer, teal = inner) point at different positions of the same list, because each iter(nums) minted its own player. That independence is exactly what lets all four pairs print. Output: (1,1)(1,2)(2,1)(2,2).

(In the figure: the two cream boxes are the shared list nums; the orange arrow is outer-loop iterator A sitting at value 1, the teal arrow is inner-loop iterator B sitting at value 2. Neither arrow can disturb the other's position — that is the whole point.)

Shared-iterator version — 2 pairs, then done.

it = iter([1, 2])
for a in it:        # outer press → a = 1, position now at 2
    for b in it:    # inner presses: b = 2, then StopIteration
        print(a, b) # prints (1, 2)

Now there is only one player, so the inner loop consumes the same position, exhausting it. When the outer loop presses again it immediately gets the "end of tape" click. Output: only (1, 2). This is the concrete reason a list is deliberately not its own iterator.

Trace UpTo(3) (stop = 3):

Wait — it does print 0, 1, 2. The subtle bug appears at the boundary case UpTo(1): expected [0].

That still gives [0]. Now UpTo(0), expected []:

Gives []. So the class is actually correct for all these — the check-after-increment happens to work because we saved value before incrementing.

The real fragility: the exhaustion check runs after mutating state, so if you ever add code between value = self.n and the check, a wrong value leaks. The robust pattern (parent note's Countdown) checks exhaustion first:

def __next__(self):
    if self.n >= self.stop:      # check FIRST
        raise StopIteration
    value = self.n
    self.n += 1
    return value

Both give [0,1,2] for UpTo(3), but check-first is the pattern that survives edits.

class MyRange:
    def __init__(self, start, stop, step=1):
        if step == 0:
            raise ValueError("step must not be zero")
        self.current = start
        self.stop = stop
        self.step = step
    def __iter__(self):
        return self
    def __next__(self):
        # check-first, and the stop test depends on step's SIGN
        if self.step > 0:
            done = self.current >= self.stop
        else:
            done = self.current <= self.stop
        if done:
            raise StopIteration
        value = self.current
        self.current += self.step
        return value

Why the sign split? With a positive step we walk upward and stop when we reach/pass stop from below (current >= stop). With a negative step we walk downward and must stop from above (current <= stop). One fixed comparison cannot cover both directions — the halting condition literally flips with the sign.

Checks (all match list(range(...))):

• (0,5,1) → [0,1,2,3,4]
• (2,10,3) → [2,5,8]
• (5,0,-1) → [5,4,3,2,1]
• (0,0,1) → [] (start already ≥ stop, immediate StopIteration)
• step=0 → ValueError (matches real range, which forbids zero step).

The original is one-shot: __iter__ returns self, so self.current is consumed by the first loop and never resets. The second loop starts from the exhausted state and yields nothing.

Fix — separate iterable from iterator (bag vs player). The iterable stores the recipe; each __iter__ births a fresh player:

class MyRangeReusable:
    def __init__(self, start, stop, step=1):
        if step == 0: raise ValueError("step must not be zero")
        self.start, self.stop, self.step = start, stop, step
    def __iter__(self):
        return MyRange(self.start, self.stop, self.step)  # new tape player

Now r = MyRangeReusable(0, 3, 1); list(r) → [0,1,2] and a second list(r) → [0,1,2] again, because each call to iter(r) (inside list) makes a brand-new MyRange with its own current.

Evens yields 0, 2, 4, 6, 8, … forever (self.n starts at -2, first next makes it 0). list(Evens()) would loop forever — we must bound it.

(a) Manual:

ev = Evens()
out = []
for _ in range(5):        # bound = 5 presses only
    out.append(next(ev))
# out == [0, 2, 4, 6, 8]

(b) islice:

from itertools import islice
out = list(islice(Evens(), 5))   # [0, 2, 4, 6, 8]

islice(iterator, 5) presses next at most 5 times, then stops — it never asks the infinite source for a 6th item, so nothing hangs.

Key idea: a tape player has no rewind, so to "peek" we must pull one item and stash it in a buffer, then hand it out on the next real next.

_SENTINEL = object()          # a unique "nothing buffered" marker
 
class Peekable:
    def __init__(self, it):
        self._it = iter(it)   # be tolerant: accept any iterable
        self._buf = _SENTINEL
    def __iter__(self):
        return self
    def __next__(self):
        if self._buf is not _SENTINEL:      # something was peeked
            value, self._buf = self._buf, _SENTINEL
            return value
        return next(self._it)               # normal press; may raise StopIteration
    def peek(self, default=_SENTINEL):
        if self._buf is _SENTINEL:          # nothing stashed yet
            try:
                self._buf = next(self._it)  # pull one and stash it
            except StopIteration:
                if default is _SENTINEL:
                    raise                   # empty and no default → re-raise
                return default              # empty but caller gave a fallback
        return self._buf                    # hand back the stashed item, unconsumed

Why the sentinel and not None? A real stream might legitimately contain None; using None as "empty" would confuse a buffered None with "buffer empty." A unique object() can never collide with real data.

Trace on Peekable(iter([1, 2])):

The two peek() calls both return 1 and do not advance; the first real next() still yields 1. That is the whole contract.

• Can you state the one-line test that separates iterable from iterator? ::: hasattr(obj, '__next__') — has it ⇒ iterator.
• Why does nested for over a list work but over a shared iterator fail? ::: A list gives each loop a fresh iterator (independent position); a shared iterator has one position that the inner loop exhausts.
• Why must MyRange's stop test depend on the step's sign? ::: Positive step halts from below (>= stop), negative step halts from above (<= stop); one comparison can't cover both directions.
• How do you take 5 items from an infinite iterator safely? ::: Bound it — manual next in range(5) or itertools.islice(it, 5).