Las dos lecciones anteriores dejaron un problema muy concreto sobre la mesa. La lista resolvió el «muchas tareas», pero para guardar los campos de cada tarea nos obligó a mantener cinco listas paralelas sincronizadas a mano: un pop olvidado y el listado empieza a mentir. El motivo de fondo es que en una lista los datos se identifican por posición, y la posición no significa nada: tarea[1] no dice si el 1 es el responsable o la prioridad.

Esta lección presenta dos estructuras que resuelven problemas distintos y que casi siempre se enseñan juntas. El diccionario guarda cada dato con su nombre, de modo que tarea["responsable"] se explica solo. El conjunto guarda elementos únicos sin orden, y es la herramienta correcta para preguntas del tipo «¿está esto aquí?» o «¿qué etiquetas distintas usamos?». Al final, TareaFácil dará el salto a la v0.9 y una tarea pasará a ser, por fin, una sola cosa.

1. Clave y valor: el problema que resuelve el diccionario
2. Crear diccionarios y acceder a sus valores
3. Añadir, modificar y borrar
4. Recorrer un diccionario
5. update, setdefault y qué puede ser una clave
6. Diccionario por comprensión y conteo de frecuencias
7. Conjuntos: elementos únicos y sin orden
8. Operaciones entre conjuntos
9. Usos típicos de los conjuntos
10. Lista, diccionario o conjunto: tabla de decisión
11. TareaFácil v0.9: la tarea es un diccionario
12. Errores comunes y consejos
13. Ejercicios
14. Conclusión

Un diccionario (tipo dict) es una colección de pares clave → valor. La clave sustituye al índice numérico: en vez de recordar que el responsable está en la posición 1, lo pides por su nombre.

Compara las dos formas de guardar la misma tarea:

Esa última fila es la regla de decisión: lista para «muchos», diccionario para «uno con varios campos». Los responsables del estudio son una lista (["Marta", "Luis", "Nuria"]); una tarea concreta es un diccionario. Y cuando quieras muchas tareas, será una lista de diccionarios, que es exactamente 05-04.

Hay dos formas de crearlo, y un diccionario vacío se escribe {}:

Para leer un valor hay, por tanto, dos caminos, y elegir bien es importante:

La regla práctica: usa d[clave] cuando la clave tiene que estar (si no está, es un error de programación y quieres enterarte), y .get() cuando su ausencia sea una posibilidad normal. Para comprobarlo explícitamente está el operador in, que en un diccionario mira las claves y no los valores: "titulo" in tarea es True, pero "Menu Sole" in tarea es False porque eso es un valor.

Añadir y modificar se escriben igual, y esa es una de las trampas del tipo: si la clave no existe, se crea; si existe, se sobrescribe sin avisar.

del es la forma directa de borrar; .pop(clave) es la que usas cuando además necesitas el valor que sale, igual que en las listas. Y como en las listas, el diccionario es mutable: si lo pasas a una función y ésta lo modifica, el cambio se ve fuera. Esto es lo que permitirá que cambiar_prioridad(tarea) funcione sin devolver nada.

Un for directo sobre un diccionario recorre las claves. Los tres métodos de vista permiten elegir qué quieres recorrer:

.items() es el que usarás el 90 % de las veces, porque casi siempre necesitas las dos cosas a la vez. Fíjate en que el desempaquetado for clave, valor in ... es el mismo mecanismo que ya viste con enumerate y zip en 05-01. Desde Python 3.7 el diccionario conserva el orden de inserción al recorrerlo, pero no te apoyes en ello para dar significado a las posiciones: si necesitas un orden concreto, pídelo explícitamente con sorted(), como en la última línea.

.update(otro) fusiona otro diccionario dentro del primero: añade las claves nuevas y sobrescribe las que coincidan. Es la forma limpia de aplicar varios cambios de golpe.

.setdefault(clave, valor) devuelve el valor de la clave si existe y, si no, la crea con el valor indicado: sirve para garantizar que una clave está presente sin machacar lo que ya hubiera. Y sobre las claves hay una regla estricta: una clave debe ser inmutable. Valen cadenas, números, booleanos y tuplas (05-04); no vale una lista ni otro diccionario.

El motivo, sin entrar en detalles: el diccionario coloca cada valor en un sitio calculado a partir de la clave, así que si la clave pudiera cambiar después, el valor quedaría perdido en un sitio equivocado. Los valores, en cambio, pueden ser lo que quieras: listas, otros diccionarios, funciones. Y las claves son únicas: escribir dos veces la misma en un literal deja solo la última.

Igual que las listas, los diccionarios admiten comprensión, con la misma sintaxis más el par clave: valor:

Y ahora un patrón clásico que aparece en todos los programas del mundo: contar frecuencias. La idea es usar el diccionario como marcador, con el elemento de clave y el recuento de valor.

La línea decisiva es conteo[nombre] = conteo.get(nombre, 0) + 1, y merece leerse despacio. conteo.get(nombre, 0) devuelve el recuento actual o 0 si es la primera vez que aparece ese nombre; se le suma 1 y se guarda. Ese 0 por defecto es lo que evita el KeyError de la primera vuelta y ahorra un if nombre in conteo:. Después, max(conteo, key=conteo.get) recorre las claves y las compara por su valor —el key de 04-05 aplicado a un diccionario— y sorted(...) ordena los pares por el segundo elemento; cómo ordena por dentro sigue siendo materia de Algoritmos de ordenamiento.

Un conjunto (set) es una colección de elementos únicos y sin orden. No hay índices: conjunto[0] da error. A cambio, responde a la pregunta «¿está esto dentro?» de forma inmediata y elimina duplicados sin esfuerzo.

El orden en que se imprime no es el de escritura y no debes contar con él. Y cuidado con la trampa de la creación que muestran las tres últimas líneas: {} no es un conjunto vacío, sino un diccionario vacío. Los métodos básicos son cuatro, y la diferencia entre los dos de borrado es la de siempre:

Existe también frozenset, la versión inmutable del conjunto: una vez creado no admite add ni remove, y su utilidad principal es poder usarse como clave de diccionario, cosa que un set normal no puede.

Aquí es donde los conjuntos brillan: implementan directamente las operaciones de la teoría de conjuntos, con operadores de una sola letra.

Partimos de marta = {"cartel", "menu", "logotipo"} y luis = {"menu", "flyer"}.

El diagrama se lee así: menu está en la zona común (la intersección), cartel y logotipo son exclusivos de Marta (la diferencia marta - luis) y flyer lo es de Luis. La unión son los cuatro; la diferencia simétrica, los tres de fuera del centro. Existe además luis <= marta, que comprueba si un conjunto está contenido en otro (aquí, False), y >= para lo contrario: son útiles para validar cosas como «¿son todas las prioridades introducidas de las admitidas?».

Dos usos cubren casi todos los casos reales. El primero, eliminar duplicados de una lista en una línea: con responsables = ["Marta", "Luis", "Marta", "Nuria", "Luis"], la expresión sorted(set(responsables)) devuelve ['Luis', 'Marta', 'Nuria']. Fíjate en el sorted(): convertir a conjunto pierde el orden original, así que si el orden importa hay que reordenar después (o usar otra técnica). El segundo uso es comprobar pertenencia en colecciones grandes: preguntar x in conjunto es muchísimo más rápido que x in lista cuando hay miles de elementos, porque el conjunto no recorre nada. El porqué exacto se estudia en Algoritmos de búsqueda y Eficiencia y notación Big-O; por ahora quédate con la consecuencia práctica: si tu programa hace muchas comprobaciones de pertenencia sobre una colección sin duplicados, esa colección debería ser un conjunto.

Las preguntas que llevan a la respuesta correcta: ¿importa el orden o voy a recorrerlos en secuencia? Lista. ¿Cada dato tiene un nombre propio? Diccionario. ¿Solo me importa si algo está o no, y no quiero repetidos? Conjunto.

En la v0.8 conseguimos muchas tareas a costa de cinco listas paralelas frágiles. Ahora vamos a arreglar la otra mitad del problema —la forma de una tarea— y para verlo con claridad volvemos temporalmente a gestionar una sola: en la v0.9 la tarea es un diccionario, y en 05-04 juntaremos las dos ideas en una lista de diccionarios.

Lo que ha cambiado respecto a la v0.7, y por qué importa:

• mostrar_ficha(tarea) tiene un parámetro en vez de cinco. Las seis variables sueltas que viajaban juntas de función en función eran, efectivamente, una sola cosa; ahora tienen nombre y forma.
• Añadir un campo ya no obliga a tocar ninguna firma. Hemos incorporado "etiqueta" sin cambiar la cabecera de nada. Con la v0.7 habría supuesto un parámetro más en cuatro funciones.
• Las funciones de acción modifican el diccionario y no devuelven nada. cambiar_prioridad(tarea) funciona porque el diccionario es mutable y se pasa por referencia, como las listas de 05-01. El nombre anuncia claramente que modifica.
• ETIQUETAS es un conjunto, porque son valores únicos sin orden cuyo uso es comprobar pertenencia y ofrecer opciones; se pasa sorted(ETIQUETAS) a pedir_opcion para que el usuario las vea siempre igual. Y tarea is None sustituye a la bandera hay_tarea: un dato menos que mantener sincronizado.

Sigue sin resolverse lo importante: solo hay una tarea. Pero ahora que una tarea es un valor único, guardarlas todas será tan fácil como meterlas en una lista.

KeyError al leer una clave que no existe. Comprueba con in o usa .get(clave, defecto). Y recuerda que las claves distinguen mayúsculas: "Titulo" y "titulo" son distintas; elige una convención (minúsculas) y respétala. Escribir mal una clave al asignar. tarea["responsble"] = "Luis" no da error: crea una clave nueva. El síntoma aparece después, cuando tarea["responsable"] devuelve el valor viejo. Es el error más traicionero del tipo.

Creer que {} es un conjunto vacío. Es un diccionario vacío; el conjunto vacío es set(). Y no esperes orden en un conjunto: si necesitas mostrarlo ordenado, sorted(conjunto).

Usar una lista como clave. TypeError: unhashable type. Si necesitas una clave compuesta, usa una tupla (05-04).

Modificar un diccionario mientras lo recorres. Añadir o borrar claves dentro del for lanza RuntimeError; recorre una copia (for c in list(d.keys()):) o construye un diccionario nuevo. Consejo: usa el diccionario para campos, no como base de datos improvisada. Si acabas con claves "tarea1", "tarea2", "tarea3", lo que quieres es una lista de diccionarios (05-04).

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

Dada la lista de responsables de las tareas abiertas, escribe un programa que imprima: cuántas tareas lleva cada persona (ordenadas de más a menos), quién lleva más, y qué miembros del equipo EQUIPO = ("Marta", "Luis", "Nuria") no tienen ninguna tarea asignada. Usa un diccionario para contar y un conjunto para la última pregunta.

Escribe crear_tarea(titulo, responsable, prioridad, dias) que devuelva el diccionario de una tarea con completada en False, y resumen(tarea) que devuelva una cadena de una línea con el título, el responsable, la prioridad en mayúsculas, los días y [X] o [ ] según el estado. Añade aplicar_cambios(tarea, cambios) que reciba un diccionario de cambios y los aplique, avisando si alguna clave no existía en la tarea.

Solución 1.

.get con defecto no falla. tarea["dias"] + 2 deja 5, y setdefault("dias", 99) no lo toca porque la clave ya existe; setdefault("prioridad", ...) sí la crea. "Cartel feria" in tarea es False porque in mira claves, no valores. El conjunto {"a","b","a","b"} tiene 2 elementos. La intersección es {'b'} y la diferencia {'a'}. Y la última línea lanza KeyError porque nunca se creó esa clave: con tarea.get("completada", False) habría devuelto False.

Solución 2.

Imprime «Marta 3 tareas», «Luis 2 tareas», «Quien lleva mas: Marta» y «Sin tareas: Nuria». La última parte es el ejemplo perfecto de para qué sirve un conjunto: set(EQUIPO) - set(asignaciones) responde «quién está en el equipo y no en las asignaciones» en una sola expresión, sin bucles ni banderas. Con listas habría hecho falta recorrer el equipo comprobando cada nombre.

Solución 3.

Lo interesante de aplicar_cambios es la comprobación if clave not in tarea. Sin ella, un error tipográfico en el nombre del campo añadiría una clave nueva en silencio —el error traicionero de la sección de consejos— y nunca sabrías por qué el cambio «no ha funcionado». Fíjate también en que la función modifica el diccionario recibido y no devuelve nada: es legítimo porque el nombre lo anuncia.

El diccionario guarda pares clave → valor y sustituye la posición por el nombre: se crea con {} o dict(), se lee con d[clave] —que lanza KeyError si falta— o con .get(clave, defecto) —que no falla—, se amplía y se modifica con la misma asignación, y se recorre con .keys(), .values() y sobre todo .items(). .update() fusiona, .setdefault() garantiza sin machacar, las claves deben ser inmutables y únicas, y la comprensión de diccionario y el patrón de conteo de frecuencias con .get(x, 0) + 1 resuelven en tres líneas cosas que antes costaban veinte. El conjunto guarda elementos únicos sin orden, no se indexa, se crea con {...} o set() —nunca con {}, que es un diccionario—, y ofrece unión |, intersección &, diferencia - y diferencia simétrica ^, además de ser la estructura correcta para deduplicar y para comprobar pertenencia.

TareaFácil está en la v0.9 y una tarea es por fin una sola cosa: un diccionario con titulo, responsable, prioridad, dias, etiqueta y completada. mostrar_ficha(tarea) tiene un parámetro en lugar de cinco, añadir un campo ya no obliga a tocar ninguna firma, y las etiquetas del estudio viven en un conjunto. Queda un último ensamblaje: la v0.8 sabía llevar muchas tareas pero con listas paralelas frágiles, y la v0.9 sabe representar una tarea perfectamente pero solo lleva una. Juntar ambas ideas —una lista de diccionarios— es lo que hace Tuplas y estructuras anidadas, donde además conocerás la tupla, entenderás por fin qué devolvía return a, b desde 04-02 y aprenderás a leer expresiones como agenda[0]["responsable"] sin pestañear.