Listas, tuplas, diccionarios, conjuntos y cadenas: el arsenal básico está completo, y el catálogo de Papyrus vive por fin en una sola estructura. Pero la biblioteca estándar (03-05) guarda un módulo pensado exactamente para pulir los patrones que hemos ido improvisando: collections. Aquí saldamos la promesa de 04-02 con namedtuple a fondo, contamos los libros más vendidos con Counter, agrupamos pedidos por cliente con defaultdict y montamos una cola de reservas eficiente con deque — y cerramos el módulo con la tabla de criterio definitiva: qué estructura elegir en cada situación.

1. namedtuple: registros con nombre, a fondo
2. Counter: contar sin bucles
3. defaultdict: diccionarios con valor por defecto
4. deque: colas eficientes por los dos extremos
5. OrderedDict: nota histórica
6. Criterios de elección: la tabla-resumen del módulo

En 04-02 la probamos como aperitivo; ahora, el plato completo. Una namedtuple es una fábrica de clases de tuplas: defines el nombre del registro y sus campos, y obtienes un tipo nuevo cuyas instancias son tuplas con campos accesibles por nombre.

Tres utilidades extra que conviene conocer:

¿Y el catálogo? La namedtuple compite con el dict anidado de 04-03, y la elección es una decisión de diseño real:

Con la opción B, un error tipográfico (ficha["precoi"]) que en el dict crearía silenciosamente una clave nueva, aquí falla al instante (AttributeError). A cambio, actualizar el stock exige _replace() y reasignar — incómodo para datos que cambian a cada venta. Para Papyrus mantenemos el dict anidado como estructura canónica mutable y usamos namedtuple para registros de solo lectura, como las líneas de un ticket ya cobrado.

Contar apariciones es tan común que collections lo trae resuelto. Counter es un diccionario especializado: claves = elementos, valores = cuántas veces aparecen.

Compara con la alternativa manual — el bucle con if titulo in cuentas: ... else: ... que habrías escrito en el módulo 2 — y aprecia la diferencia: most_common() te da el ranking de superventas de Ana en una llamada, listo para el escaparate. Como es un dict con esteroides, todo lo de 04-03 funciona: items(), comprensiones, in...

Patrón clásico: agrupar cosas. Ana quiere los pedidos organizados por cliente. Con un dict normal hay que comprobar si la clave existe antes de hacer append:

defaultdict elimina la ceremonia: se construye con una fábrica (una función sin argumentos, como list, int o set) que se invoca automáticamente la primera vez que se accede a una clave inexistente:

Matiz importante: leer también crea. por_cliente["Nadie"] inserta "Nadie": [] solo por consultarlo. Si vas a hacer muchas consultas de solo lectura, conviértelo antes a dict normal (dict(por_cliente)) o usa get().

En 04-01 montamos la cola de pedidos con una lista y avisamos: pop(0) desplaza todos los elementos restantes. deque (double-ended queue, se pronuncia "dec") está optimizada para añadir y quitar por ambos extremos sin desplazar nada:

El maxlen es una joya para "las N últimas operaciones" (historial del menú de Papyrus, por ejemplo): se mantiene solo. La contrapartida de deque: acceder por índice al medio (reservas[500]) es lento comparado con una lista. Regla: extremos → deque; posiciones interiores → lista.

En código antiguo verás collections.OrderedDict: un dict que garantizaba el orden de inserción cuando los dicts normales no lo hacían. Desde Python 3.7 todos los dict conservan el orden, así que hoy casi nunca lo necesitas. Sobrevive por compatibilidad y por dos detalles menores (su igualdad sí compara el orden, y tiene move_to_end()). Si lo ves en un tutorial, ya sabes por qué está ahí — y que puedes usar un dict normal.

La decisión de estructura es la primera decisión de diseño de cualquier programa. Todo el módulo 4, en una tabla:

Y como guía de decisión rápida:

• Olvidar el import: NameError: name 'Counter' is not defined. Todo lo de esta lección vive en collections: from collections import Counter, defaultdict, deque, namedtuple.
• Mutar una namedtuple: libro.stock = 3 lanza AttributeError. Es una tupla: usa _replace() y reasigna, o reconoce que ese dato pedía un dict.
• defaultdict que "engorda" solo: cada lectura de clave nueva la crea. Para consultar sin crear, d.get(clave) o convertir a dict al terminar de construir.
• Usar Counter como validador de existencia: contador["X"] devuelve 0 en vez de KeyError, así que if contador["X"]: es correcto pero contador["X"] jamás delatará una clave mal escrita.
• Indexar el medio de una deque en bucle: para eso es mala; si necesitas posiciones interiores, era una lista.
• Elegir estructura por costumbre ("todo listas"): revisa la tabla. La estructura correcta elimina código — el gran refactor de 04-03 borró más líneas de las que añadió.
• Consejo: Counter, defaultdict y deque son dicts/colas normales en su interfaz; todo lo aprendido en 04-03 y 04-01 les aplica. No son estructuras nuevas que aprender, sino atajos sobre las que ya dominas.

1. Ranking de superventas. Con ventas = ["Hamlet", "El Quijote", "Hamlet", "La Odisea", "Hamlet", "El Quijote", "Fausto"], usa Counter para imprimir el podio (top 3) con formato 1. Hamlet — 3 uds. usando most_common() y enumerate(start=1) (módulo 2, al rescate). Añade el total de ejemplares vendidos.
2. Agrupador de reservas. Con la lista de tuplas reservas = [("Fausto", "Luis"), ("Fausto", "Marta"), ("Ilíada", "Luis"), ("Fausto", "Pau")], construye con defaultdict(list) el dict titulo → [clientes en orden]. Después convierte la lista de "Fausto" en una deque y simula la llegada de 2 ejemplares: haz popleft() dos veces e informa a quién se avisa y quién sigue esperando.
3. Ticket inmutable. Define la namedtuple LineaTicket con campos titulo, unidades e importe. Crea las líneas de una compra de Luis (2 "Hamlet" a 9.83 cada uno → importe 19.66; 1 "El Quijote" → 15.71), guárdalas en una lista e imprime el ticket con f-strings alineadas (04-05) y el total con sum() y una expresión generadora sobre .importe.

Fíjate: most_common(3) devuelve tuplas (titulo, unidades), y el for las desempaqueta dentro del par de enumerate — desempaquetado anidado con paréntesis.

Consejo: las líneas de un ticket cobrado no deben cambiar jamás — la inmutabilidad de la namedtuple no es una limitación aquí, es exactamente la garantía que el negocio necesita.

El módulo 4 cumple lo que prometió al cerrar el módulo 3: cada libro de Papyrus es por fin una sola pieza de información. Repasaste las listas a fondo con su mutabilidad y sus trampas de alias (04-01); las tuplas te dieron registros inmutables y el retorno múltiple que 03-02 dejó prometido (04-02); los diccionarios ejecutaron el gran refactor — el catálogo es hoy {título: {"precio": ..., "stock": ...}} con acceso directo por clave (04-03); los conjuntos aportaron unicidad, pertenencia ultrarrápida y álgebra para comparar socios y deduplicar pedidos (04-04); las cadenas revelaron su caja de herramientas completa y la normalización definitiva de buscar_libro() (04-05); y collections puso nombre a los patrones que faltaban — namedtuple, Counter, defaultdict, deque — junto con la tabla de criterio para elegir estructura sin dudar. Pero mira el código de Papyrus con ojos nuevos: el catálogo vive en un diccionario y las funciones que saben operarlo — buscar_libro(), mostrar_catalogo(), precio_final() — viven aparte, en papyrus_utils.py, confiando en que nadie les pase una estructura equivocada. Datos por un lado, comportamiento por otro. El módulo 5 presenta la herramienta que los une en una sola pieza con nombre propio: las clases. Cada libro dejará de ser una entrada de diccionario para convertirse en un objeto que sabe calcular su propio precio de socio — la programación orientada a objetos empieza donde las estructuras de datos terminan.