Si trabajas con listas de datos en Python y quieres código más corto y legible, las comprensiones son tu mejor herramienta. Aquí aprenderás a transformar bucles tradicionales en set comprehensions y dictionary comprehensions anidadas, partiendo de un caso real: extraer y categorizar noticias por su fuente.

Este contenido es ideal si ya dominas los for tradicionales y quieres dar el salto hacia un código más pythónico sin perder claridad.

Cómo extraer fuentes únicas con un set en Python

El reto arranca con una lista de artículos. Cada artículo tiene un title y una source, y esa fuente es un diccionario con un name. El objetivo es obtener todas las fuentes sin repetir ninguna.

La solución tradicional usa una función get_sources que crea un set vacío. ¿Por qué un set y no una lista? Porque el set no admite duplicados: si el dato ya existe, simplemente no lo agrega [00:36].

Dentro de la función iteramos con for article in articles y validamos dos cosas antes de agregar:

• Que el artículo tenga una fuente usando get.
• Que esa fuente tenga un name.

Esa validación doble se hace con un ampersand (operador and): si existe la fuente, obtenemos el nombre y lo agregamos con el método add [01:15]. Al terminar la iteración, retornamos el set.

¿Para qué sirve un set en Python? Es una estructura que guarda valores sin duplicados. Si agregas "tech news" dos veces, solo queda una copia. Perfecto para listar fuentes o categorías únicas.

Cómo refactorizar un for a set comprehension

Aquí viene lo interesante: ese mismo código de varias líneas cabe en una sola con una comprensión. La sintaxis reordena las tres piezas que ya conoces.

1. La expresión: lo que quieres dejar dentro del set.
2. El for: la iteración sobre los artículos.
3. El if: la condición opcional al final.

Envolviendo todo entre llaves {} creas un set directamente [02:24]. Copias el for y el if (sin los dos puntos) y colocas al inicio lo que quieres guardar.

Al comparar ambas versiones con un print, el resultado es idéntico: aunque el set de pruebas tenga "tecnología" repetida, solo aparece una vez "tech news" [03:14].

Cómo categorizar noticias con diccionarios anidados

Muchos modelos de negocio necesitan iteraciones anidadas, y las comprensiones también las soportan. El siguiente paso es agrupar todas las noticias según su categoría, generando una lista de artículos por cada fuente.

La versión tradicional, categorizar_tradicional, reutiliza get_sources para obtener la lista de fuentes y luego hace dos iteraciones anidadas [04:15]. El resultado es un diccionario donde:

• La llave es la categoría (la fuente).
• El valor es la lista de artículos que coinciden.

Antes de agregar cualquier artículo, hay que crear la llave. Con un condicional not in verificamos si la fuente ya existe en results; si no, la definimos como una lista vacía [05:07]. Esto evita que la lista se reinicie en cada vuelta y borre los artículos ya agregados.

¿Por qué validar con not in antes de agregar a un diccionario? Porque si no verificas, cada iteración sobrescribe la lista con una vacía y pierdes los datos previos. El not in solo crea la llave la primera vez.

Después iteramos sobre los artículos y, con otro if, comparamos si la fuente externa es igual al nombre de la fuente del artículo. Si coinciden, lo sumamos con el método append [06:00].

Cómo convertir dos for anidados en una comprensión

Pasar esto a una comprensión de diccionario evita tener que crear la lista vacía manualmente, porque se genera sola en cada iteración.

La lógica se lee así: trae todas las fuentes, itera sobre ellas y usa cada fuente como llave del diccionario. Dentro del valor, que es una lista, itera los artículos y agrega cada uno solo si su fuente coincide con la que estás recorriendo [07:36].

Al probar ambas versiones con un separador entre los print, el output es exactamente igual [08:13]. La diferencia es que la comprensión anidada elimina el código extra de inicializar llaves.

Cuándo conviene usar comprensiones en tu código

Las comprensiones funcionan en listas, diccionarios y sets, pero no son una regla obligatoria. Úsalas cuando mejoren la legibilidad, no cuando compliquen la lectura.

Tres recomendaciones prácticas del cierre de la clase:

• Revisa el rendimiento de los for de tu aplicación y mejóralos con list o set comprehensions [08:33].
• Aplica comprensiones solo cuando hagan el código más claro y corto.
• Después de cada refactor, valida que las funciones sigan importando y exportando la información correctamente [08:48].

Un detalle curioso del ejemplo: el editor marcó un error de variable no definida porque el nombre del sample no coincidía, algo que herramientas como estas detectan automáticamente [06:40]. Corregirlo fue tan simple como usar la variable correcta.

¿Ya intentaste refactorizar alguno de tus bucles a comprensiones? Cuéntame en los comentarios qué tan legible te quedó el código.