Lists, tuples, dictionaries, sets and strings: the basic arsenal is complete, and the Papyrus catalog finally lives in a single structure. But the standard library (03-05) holds a module designed precisely to polish the patterns we have been improvising: collections. Here we settle the promise from 04-02 with namedtuple in depth, count the best-selling books with Counter, group orders by customer with defaultdict and build an efficient reservation queue with deque — and we close the module with the definitive decision table: which structure to choose in each situation.

1. namedtuple: named records, in depth
2. Counter: counting without loops
3. defaultdict: dictionaries with a default value
4. deque: efficient queues at both ends
5. OrderedDict: a historical note
6. Choosing criteria: the module's summary table

In 04-02 we tried it as an appetizer; now, the full course. A namedtuple is a factory of tuple classes: you define the record's name and its fields, and you get a new type whose instances are tuples with fields accessible by name.

Three extra utilities worth knowing:

What about the catalog? The namedtuple competes with 04-03's nested dict, and the choice is a real design decision:

With option B, a typo (record["pirce"]) that in the dict would silently create a new key fails instantly here (AttributeError). In exchange, updating the stock requires _replace() plus reassignment — awkward for data that changes with every sale. For Papyrus we keep the nested dict as the canonical mutable structure and use namedtuple for read-only records, such as the lines of an already-charged receipt.

Counting occurrences is so common that collections ships it ready-made. Counter is a specialized dictionary: keys = elements, values = how many times they appear.

Compare with the manual alternative — the loop with if title in counts: ... else: ... that you would have written in module 2 — and appreciate the difference: most_common() hands Ana her bestseller ranking in one call, ready for the shop window. Since it is a dict on steroids, everything from 04-03 works: items(), comprehensions, in...

A classic pattern: grouping things. Ana wants the orders organized by customer. With a regular dict you have to check whether the key exists before doing append:

defaultdict removes the ceremony: you build it with a factory (a zero-argument function, such as list, int or set) that gets invoked automatically the first time a missing key is accessed:

An important nuance: reading also creates. by_customer["Nobody"] inserts "Nobody": [] just by looking it up. If you are going to do many read-only lookups, convert it to a regular dict first (dict(by_customer)) or use get().

In 04-01 we built the order queue with a list and gave a warning: pop(0) shifts every remaining element. deque (double-ended queue, pronounced "deck") is optimized for adding and removing at both ends without shifting anything:

maxlen is a gem for "the last N operations" (the Papyrus menu's history, for instance): it maintains itself. The trade-off of deque: accessing the middle by index (reservations[500]) is slow compared to a list. Rule: ends → deque; interior positions → list.

In older code you will see collections.OrderedDict: a dict that guaranteed insertion order back when regular dicts did not. Since Python 3.7 all dicts preserve order, so today you almost never need it. It survives for compatibility and for two minor details (its equality does compare order, and it has move_to_end()). If you see it in a tutorial, now you know why it is there — and that you can use a regular dict.

The choice of structure is the first design decision of any program. All of module 4, in one table:

And as a quick decision guide:

• Forgetting the import: NameError: name 'Counter' is not defined. Everything in this lesson lives in collections: from collections import Counter, defaultdict, deque, namedtuple.
• Mutating a namedtuple: book.stock = 3 raises AttributeError. It is a tuple: use _replace() and reassign, or admit that piece of data was asking for a dict.
• A defaultdict that "fattens up" on its own: every read of a new key creates it. To look up without creating, d.get(key) or convert to dict once you finish building.
• Using Counter as an existence validator: counter["X"] returns 0 instead of KeyError, so if counter["X"]: is correct but counter["X"] will never expose a misspelled key.
• Indexing the middle of a deque in a loop: that is what it is bad at; if you need interior positions, it was a list.
• Choosing a structure out of habit ("everything is a list"): review the table. The right structure removes code — 04-03's great refactor deleted more lines than it added.
• Tip: Counter, defaultdict and deque are regular dicts/queues in their interface; everything you learned in 04-03 and 04-01 applies to them. They are not new structures to learn, but shortcuts over the ones you already master.

1. Bestseller ranking. With sales = ["Hamlet", "Don Quixote", "Hamlet", "The Odyssey", "Hamlet", "Don Quixote", "Faust"], use Counter to print the podium (top 3) in the format 1. Hamlet — 3 units using most_common() and enumerate(start=1) (module 2, to the rescue). Add the total number of copies sold.
2. Reservation grouper. With the list of tuples reservations = [("Faust", "Luis"), ("Faust", "Marta"), ("The Iliad", "Luis"), ("Faust", "Pau")], build with defaultdict(list) the dict title → [customers in order]. Then turn the "Faust" list into a deque and simulate the arrival of 2 copies: do popleft() twice and report who gets notified and who is still waiting.
3. Immutable receipt. Define the namedtuple ReceiptLine with fields title, units and amount. Create the lines of a purchase by Luis (2 "Hamlet" at 9.83 each → amount 19.66; 1 "Don Quixote" → 15.71), store them in a list and print the receipt with aligned f-strings (04-05) and the total with sum() and a generator expression over .amount.

Notice: most_common(3) returns (title, units) tuples, and the for unpacks them inside the pair from enumerate — nested unpacking with parentheses.

Tip: the lines of a charged receipt must never change — the namedtuple's immutability is not a limitation here, it is exactly the guarantee the business needs.

Module 4 delivers what it promised when module 3 closed: each Papyrus book is finally a single piece of information. You revisited lists in depth with their mutability and their alias traps (04-01); tuples gave you immutable records and the multiple return values that 03-02 left promised (04-02); dictionaries carried out the great refactor — the catalog is now {title: {"price": ..., "stock": ...}} with direct access by key (04-03); sets contributed uniqueness, lightning-fast membership and algebra for comparing members and deduplicating orders (04-04); strings revealed their complete toolbox and find_book()'s definitive normalization (04-05); and collections gave names to the remaining patterns — namedtuple, Counter, defaultdict, deque — along with the decision table for choosing a structure without hesitation. But look at the Papyrus code with fresh eyes: the catalog lives in a dictionary and the functions that know how to operate it — find_book(), show_catalog(), final_price() — live elsewhere, in papyrus_utils.py, trusting that nobody hands them the wrong structure. Data on one side, behavior on the other. Module 5 introduces the tool that fuses them into a single piece with a name of its own: classes. Each book will stop being a dictionary entry and become an object that knows how to compute its own member price — object-oriented programming begins where data structures end.