Al cerrar la lección anterior quedaba un ensamblaje pendiente. La v0.8 sabía llevar muchas tareas, pero repartidas en listas paralelas que había que sincronizar a mano; la v0.9 sabe describir una tarea impecablemente, pero solo lleva una. Las dos piezas encajan de forma casi obvia: si una tarea es un diccionario y una lista guarda muchas cosas del mismo tipo, entonces la agenda de Estudio Alba es una lista de diccionarios. Esta lección trata de eso —de combinar estructuras— y de la última que faltaba por conocer: la tupla, una secuencia inmutable que ya te has encontrado sin saberlo cada vez que una función devolvía dos valores en 04-02. Al terminar sabrás leer sin dudar expresiones como agenda[0]["responsable"], elegir con criterio entre lista, diccionario y tupla, y TareaFácil habrá alcanzado la v0.10 con todo su menú funcionando sobre una colección real.

1. Qué es una tupla
2. Inmutabilidad: cuándo tupla y cuándo lista
3. Desempaquetado
4. Devolver varios valores es devolver una tupla
5. Tuplas como claves y namedtuple
6. Estructuras anidadas: los tres patrones
7. Leer una expresión encadenada
8. Recorrer estructuras anidadas
9. Copia superficial y copia profunda
10. Elegir la estructura adecuada
11. TareaFácil v0.10: la agenda del estudio
12. Errores comunes y consejos
13. Ejercicios
14. Conclusión

Una tupla es una secuencia ordenada de valores, como una lista, pero inmutable: una vez creada no se puede añadir, quitar ni cambiar nada. Se escribe con paréntesis, aunque lo que de verdad crea la tupla son las comas.

Índices, rebanadas, len(), in y el recorrido con for funcionan exactamente igual que en una lista; lo único que no funciona es modificar. Las tres últimas asignaciones son las que despistan a todo el mundo: los paréntesis son opcionales, la tupla vacía se escribe () y la tupla de un elemento exige la coma final, porque sin ella los paréntesis son de agrupación y el resultado es el valor de dentro. Las constantes que llevas usando desde 04-04 —PRIORIDADES = ("alta", "media", "baja")— son precisamente tuplas, y ahora sabes por qué: son datos fijos que el programa no debe cambiar nunca.

La pregunta que decide es: ¿los elementos son cosas distintas con un papel fijo, o muchas cosas iguales? Una coordenada (x, y), una fecha (2026, 8, 4) o una fila de datos son tuplas: número fijo de posiciones, cada una con su significado. Los responsables del estudio son una lista: puede crecer, menguar y reordenarse. La inmutabilidad tiene tres ventajas prácticas: protege los datos que no deben cambiar, permite usar la tupla como clave de diccionario o elemento de un conjunto, y documenta la intención a quien lee el código, porque una tupla dice «esto es un registro cerrado». La contrapartida es que para cambiar algo hay que construir una tupla nueva.

Desempaquetar es repartir los elementos de una secuencia en varias variables de una sola vez. Es una de las cosas que hacen a Python cómodo, y ya lo has usado sin nombrarlo en for clave, valor in tarea.items().

El número de nombres a la izquierda debe coincidir exactamente con el de elementos; si no, ValueError: too many values to unpack. El intercambio en una línea funciona porque el lado derecho se evalúa entero antes de asignar: primero se construye la tupla (5, 3) y luego se reparte. El asterisco recoge «el resto» en una lista, y solo puede haber uno por desempaquetado. El guion bajo _ es una convención, no una regla del lenguaje: una variable normal cuyo nombre anuncia que su valor se va a ignorar.

En 04-02 aprendiste que una función puede devolver varios valores y quedó dicho que se explicaría aquí. Ya tienes todas las piezas: return a, b construye una tupla y la devuelve; la asignación múltiple en la llamada es un desempaquetado.

Es decir: una función siempre devuelve un único valor; lo que pasa es que ese valor puede ser una tupla con varias cosas dentro. Aquella registrar_tarea() de la v0.7, que «devolvía cuatro valores», devolvía en realidad una tupla de cuatro elementos que se desempaquetaba en la llamada. Consejo de diseño: si vuelves de una función con más de tres o cuatro valores, o si quien llama tiene que recordar el orden exacto, probablemente lo que quieres devolver es un diccionario, donde cada dato lleva su nombre. Es justo el cambio que hizo la v0.9.

Al ser inmutable, una tupla puede ser clave de un diccionario. Eso permite indexar por una combinación de datos:

Con una lista como clave sería imposible (TypeError: unhashable type). Este patrón es habitual para tablas de doble entrada: persona y día, producto y mes, fila y columna. Existe también namedtuple, del módulo collections, que es una tupla cuyos campos tienen nombre: Tarea = namedtuple("Tarea", "titulo responsable dias") permite escribir t.responsable en lugar de t[1]. La menciono para que la reconozcas si la encuentras; en este curso usaremos diccionarios para lo mismo, y en el módulo 7 verás la herramienta definitiva, las clases.

Listas, diccionarios y tuplas se pueden meter unos dentro de otros sin límite, pero en la práctica casi todo lo que necesitarás son tres combinaciones. La primera es la lista de diccionarios — «muchos registros»—, la forma natural de una agenda, un catálogo o una tabla:

Diccionario de listas — «grupos de cosas», cuando quieres ir directo al nombre del grupo. Y diccionario de diccionarios — «fichas indexadas por un identificador único»:

Se accede a ellos con agenda[0]["titulo"], por_responsable["Marta"][0] y equipo["Marta"]["rol"] respectivamente. La tabla de decisión completa está en la sección 10.

Una expresión como agenda[0]["responsable"] asusta la primera vez y deja de hacerlo en cuanto sabes que se lee de izquierda a derecha, un paso cada vez:

1. agenda → la lista completa de tareas.
2. agenda[0] → el primer elemento de esa lista, que resulta ser un diccionario.
3. agenda[0]["responsable"] → el valor de la clave "responsable" de ese diccionario, "Marta".

El truco para no perderte: cada corchete baja un nivel del árbol. Si dudas, imprime los pasos intermedios en el REPL: print(agenda[0]) enseña el diccionario entero y print(type(agenda[0])) dice en qué tipo estás parado. Los errores son informativos: TypeError: list indices must be integers significa que has usado una clave de texto donde había una lista, y KeyError, que la clave no existe en ese diccionario. Con la práctica se leen de un vistazo: agenda[1]["titulo"] es "Menu Sole", equipo["Marta"]["rol"] es "coordinadora", por_responsable["Marta"][1] es "Flyer verano", y agenda[0]["dias"] = 4 modifica la tarea en el sitio sin ningún problema.

Recorrer una lista de diccionarios es un for normal en el que cada elemento resulta ser un diccionario:

Aquí se ve por qué merecía la pena el cambio: ordenar por días, que en 05-01 era una expresión retorcida con titulos.index(t), ahora es simplemente key=lambda t: t["dias"]. Recorrer un diccionario de listas exige dos niveles de bucle, el segundo dentro del primero; con un diccionario de diccionarios el patrón es el mismo:

Fíjate en el desempaquetado directo en el encabezado: for responsable, titulos in ...items() separa clave y valor sin líneas extra, y funciona siempre que la estructura interna sea conocida.

Aquí aparece un error clásico que solo se manifiesta con estructuras anidadas: .copy() copia la lista, pero no copia lo que hay dentro.

La lista copia es nueva, pero sus elementos son los mismos diccionarios que los de agenda: se ha duplicado la caja, no el contenido.

La regla práctica: si la estructura tiene un solo nivel, la copia superficial basta; si hay listas o diccionarios dentro y vas a modificarlos, necesitas deepcopy. Y no uses deepcopy por defecto: es más lenta, y la mayoría de las veces lo que quieres precisamente es que la función modifique la agenda de verdad.

Un consejo que ahorra mucho trabajo: elige la estructura pensando en la operación más frecuente. Si lo que más haces es recorrer todo y ordenar, lista de diccionarios; si lo que más haces es «dame la ficha de X», diccionario de diccionarios. Y si necesitas las dos cosas, mantener una lista y construir el agrupamiento cuando haga falta suele ser más simple que sostener dos estructuras sincronizadas —el error que ya cometimos con las listas paralelas.

Llegamos al ensamblaje: la agenda es una lista de diccionarios y todas las opciones del menú se rehacen sobre ella, que crece a seis para incluir el resumen por responsable. Las listas paralelas de la v0.8 desaparecen para siempre.

Los puntos que conviene entender bien:

• elegir_tarea devuelve el diccionario, no un índice. Y como el diccionario es mutable y se pasa por referencia, cambiar_prioridad(tarea) modifica la tarea dentro de la agenda sin necesidad de saber en qué posición estaba. Compara esto con los cinco pop coordinados de la v0.8.
• sorted(enumerate(agenda, start=1), key=lambda p: ORDEN_PRIORIDAD[p[1]["prioridad"]]) ordena por el orden lógico de las prioridades —usando un diccionario como tabla de traducción— sin perder el número real de cada tarea: enumerate produce pares (numero, tarea) y el key mira dentro del segundo elemento del par. Así el listado sale ordenado pero los números siguen sirviendo para elegir, y elegir_tarea puede reutilizar mostrar_listado en lugar de repetir el bucle (DRY, 04-04).
• sum(1 for t in agenda if t["completada"]) cuenta las completadas sin bucle explícito, y sum(t['dias'] for t in agenda) acumula los días: comprensiones de 05-01 usadas dentro de sum.
• resumen.setdefault(responsable, {...}) crea la ficha del responsable la primera vez que aparece y la devuelve las siguientes: el patrón de conteo de 05-03, aquí construyendo un diccionario de diccionarios sobre la marcha. Y {n.capitalize() for n in EQUIPO} - set(resumen) es un conjunto por comprensión menos otro conjunto: quién del equipo no tiene nada asignado, en una línea. Por último, if not agenda: aprovecha que una lista vacía es falsa (02-04) y se lee mejor que len(agenda) == 0.

Con esto TareaFácil hace por fin lo que Marta necesita, y queda un solo cabo suelto, el que da título a la próxima lección: al cerrar el programa, todo desaparece.

Olvidar la coma en la tupla de un elemento. ("Marta") es una cadena; ("Marta",) es una tupla. Se nota cuando len() devuelve 5 en vez de 1. Y modificar una tupla da TypeError: si necesitas cambiar valores, usa una lista.

Desempaquetar con un número de nombres distinto. a, b = (1, 2, 3) lanza ValueError; usa a, *resto = ... si no sabes cuántos elementos vendrán. Confundir los niveles en una expresión encadenada. agenda["titulo"] falla porque agenda es una lista: primero hay que elegir un elemento (agenda[0]) y después la clave. Si te pierdes, imprime los pasos intermedios. Y copiar en superficie una estructura anidada no protege los diccionarios de dentro: usa copy.deepcopy cuando quieras un árbol independiente.

Consejo: mantén homogénea la lista de diccionarios. Que todos tengan las mismas claves es lo que permite recorrerla sin comprobaciones; si un registro puede no tener un campo, dale un valor por defecto al crearlo en lugar de omitir la clave. Y no anides más de tres niveles: datos["a"][0]["b"][2]["c"] es indescifrable y frágil. Extrae subestructuras a variables con nombre (tarea = agenda[i]) o replantea el diseño; a partir de cierta complejidad, lo que pide el problema son clases.

Di qué imprime cada línea y qué errores se producen.

Con la agenda de abajo, escribe las expresiones o el código necesarios para obtener: los títulos de las tareas de prioridad alta; el total de días pendientes (los de las tareas no completadas); la tarea con más días; la lista de títulos ordenada alfabéticamente ignorando mayúsculas; y un diccionario {responsable: numero_de_tareas}.

Escribe agrupar_por_responsable(agenda) que devuelva un diccionario de listas con los títulos de cada persona, incluyendo a los miembros de EQUIPO que no tengan ninguna tarea (con lista vacía). Después escribe pintar_grupos(grupos) que lo imprima con los responsables ordenados por número de tareas descendente y los títulos alfabéticamente.

Solución 1.

("Marta",) tiene un elemento; ("Marta") es la cadena "Marta", cuya longitud es 5. El intercambio deja a = 2 y b = 1 porque el lado derecho se evalúa entero antes de asignar. *resto recoge lo que sobra en una lista. copia es una copia superficial: sus elementos son los mismos diccionarios, así que el 99 se ve en la original. Y la última línea falla porque agenda es una lista y "titulo" no es un índice: faltaba bajar un nivel con agenda[0]["titulo"].

Solución 2.

Dos detalles. max(agenda, key=...) devuelve el diccionario entero, no los días, por eso hace falta ["titulo"] para ver el nombre. Y el key=str.lower del orden alfabético es el de 05-02: sin él, «menu Sole» iría primero por empezar en minúscula.

Solución 3.

El diccionario por comprensión inicial garantiza que todos los miembros del equipo aparezcan, aunque no tengan tareas: sin él, Nuria se quedaría fuera del informe. El setdefault que viene después cubre el caso contrario —un responsable que no esté en EQUIPO—, así que la función no se rompe con datos inesperados. Y key=lambda p: -len(p[1]) ordena de más a menos usando el truco del signo negativo, alternativa a reverse=True cuando el criterio es numérico.

Una tupla es una secuencia inmutable: lo que la crea son las comas, la de un elemento necesita la coma final (x,), y su papel natural es el registro de campos fijos, la constante y el valor devuelto. El desempaquetado reparte sus elementos en variables (titulo, responsable, dias = tarea), permite el intercambio en una línea y admite *resto para recoger lo que sobra. Con eso queda cerrada la promesa de 04-02: devolver varios valores es devolver una tupla, y una función siempre devuelve un único objeto. Al ser inmutables, las tuplas sirven como claves de diccionario para indexar por combinaciones, y namedtuple existe por si te la encuentras.

Las estructuras anidadas se reducen en la práctica a tres patrones: lista de diccionarios para muchos registros, diccionario de listas para agrupar y diccionario de diccionarios para fichas indexadas. Se leen de izquierda a derecha bajando un nivel por cada corchete, se recorren con bucles anidados y desempaquetado en el for, y esconden una trampa: la copia superficial no duplica el interior, para eso está copy.deepcopy. TareaFácil ha alcanzado la v0.10, y es un programa de verdad: la agenda es una lista de diccionarios, el listado sale numerado y ordenado por prioridad, elegir_tarea devuelve la tarea que después se modifica en el sitio, y un resumen agrupa el trabajo por responsable señalando a quien está libre. Las listas paralelas de la v0.8 y sus riesgos de desincronización han desaparecido por completo. Pero sigue habiendo un final infeliz: cuando Marta cierra el programa, la agenda entera se evapora. Toda esa estructura vive solo en la memoria. En Guardar datos en archivos: texto, CSV y JSON aprenderás a escribirla en disco y a recuperarla al arrancar, de modo que el trabajo del estudio siga ahí mañana por la mañana. Es el último cabo suelto del módulo.