Ficha🟣 Avanzado

Fundamentos de programación aplicada a problemas reales

🟣 Nivel Avanzado  ·  Tecnológicas

Si una computadora puede repetir una operación millones de veces sin cansarse, ¿por qué seguimos resolviendo a mano problemas que podrían convertirse en procesos reproducibles?

Programar no consiste simplemente en escribir instrucciones correctas. Implica decidir qué parte de un problema puede formalizarse, qué datos merecen confianza, qué decisiones deben seguir siendo humanas y cómo verificar que una automatización no produzca errores a una velocidad mayor que la que pretendía ahorrar. Esta ficha no te dará UNA respuesta. Te dará las herramientas para construir la tuya.

Qué lograrás

Objetivo didáctico

Al terminar esta ficha serás capaz de integrar programación en Python, automatización, obtención responsable de datos, análisis con pandas y visualización con matplotlib para construir una solución reproducible a un problema real, evaluando además la calidad de los datos, los límites éticos del proceso y la validez de las conclusiones obtenidas.

Punto de partida

Introducción

El valor más profundo de la programación aparece cuando deja de ser una colección de ejercicios y se convierte en una forma de intervenir sobre situaciones concretas. Un archivo con miles de registros de calidad del aire, una página pública que cambia cada día, cientos de recibos que deben clasificarse o un conjunto de datos municipales que nadie ha convertido todavía en información comprensible son problemas distintos, pero todos pueden analizarse mediante una misma pregunta: ¿qué partes de esta situación pueden representarse como datos y reglas?

Esa pregunta pertenece al terreno del pensamiento computacional. Jeannette Wing lo presentó en 2006 como una forma de abordar problemas mediante ideas como descomposición, abstracción y procedimientos susceptibles de ser ejecutados por personas o máquinas (Wing, 2006). Su alcance es mayor que aprender Python: programar bien exige decidir qué simplificar, qué conservar, qué medir y qué hacer cuando la realidad contradice al modelo.

🔷 Marco conceptual: programación como sistema de transformación verificable
Un programa aplicado puede entenderse como un sistema que recibe entradas, ejecuta transformaciones explícitas, produce salidas y permite comprobar si esas salidas conservan relación con el problema original. La calidad no depende únicamente de que el código “corra”: depende de que el modelo, los datos y la interpretación sean defendibles.

Python resulta especialmente útil para este propósito porque combina estructuras de programación general con un ecosistema orientado a automatización y datos. La documentación oficial vigente el 22 de agosto de 2026 corresponde a Python 3.14.7 y mantiene separados el tutorial del lenguaje, la biblioteca estándar, la referencia y el sistema de paquetes; esa separación recuerda algo importante: dominar el lenguaje implica aprender a combinar herramientas, no memorizar una única lista de comandos (Python Software Foundation, 2026).

En esta ficha el recorrido será deliberadamente completo. Se parte de Python intermedio para estructurar soluciones reutilizables; después se automatizan tareas; se estudia el scraping como técnica condicionada por reglas técnicas y éticas; los datos se transforman con pandas; y finalmente se convierten en una representación gráfica con matplotlib. El propósito no es sumar cinco herramientas aisladas, sino comprender cómo se enlazan en una cadena de decisiones.

El contenido

Desarrollo del tema

01

Python intermedio: de instrucciones sueltas a sistemas que pueden mantenerse

El salto desde Python elemental hacia un uso intermedio ocurre cuando el código deja de escribirse como una secuencia única y empieza a organizarse alrededor de funciones, módulos, estructuras de datos y contratos explícitos. Una función no sirve solo para evitar repetir líneas: delimita una responsabilidad. Si una operación recibe una lista de cantidades y devuelve un total normalizado, ese comportamiento puede probarse sin ejecutar el resto del programa. Esta separación reduce la cantidad de decisiones que deben mantenerse simultáneamente en la mente.

Considere un problema cotidiano: analizar consumos mensuales de agua de 240 viviendas para detectar cambios anómalos. Una solución frágil mezcla lectura del archivo, limpieza, cálculo, impresión y gráfico en un solo bloque. Una solución más madura crea funciones como cargar_datos(), limpiar_consumo() y detectar_cambios(). El número de líneas puede incluso aumentar, pero la estructura mejora porque cada parte tiene una función verificable.

La historia de Python ayuda a entender esta filosofía. Guido van Rossum comenzó a trabajar en el lenguaje a finales de 1989 y publicó sus primeras versiones a comienzos de la década de 1990. Python fue creciendo alrededor de una idea pragmática: combinar legibilidad con capacidad para construir programas reales. Décadas después, esa prioridad sigue visible en recursos como funciones de primera clase, comprensiones, módulos, manejo explícito de excepciones y anotaciones de tipo.

Una analogía útil es pensar en una cocina comunitaria que prepara 500 raciones. Un cocinero puede saber realizar cada movimiento, pero si cortar, cocinar, pesar, empacar y registrar ocurren sin estaciones diferenciadas, cualquier error contamina todo el proceso. Las funciones son esas estaciones: cada una recibe algo, realiza una responsabilidad y entrega un resultado. La programación intermedia comienza cuando se diseña el flujo antes de preocuparse por adornar cada instrucción.

def cambio_porcentual(anterior: float, actual: float) -> float:
    if anterior == 0:
        raise ValueError("El valor anterior no puede ser cero")
    return ((actual - anterior) / anterior) * 100

consumos = [18.4, 19.1, 27.8]
variaciones = [
    cambio_porcentual(a, b)
    for a, b in zip(consumos, consumos[1:])
]
Toca una etapa para examinar su función dentro de una solución programable.
02

Automatización: convertir una repetición en un proceso confiable

Automatizar significa delegar a un programa una secuencia que puede expresarse mediante reglas suficientemente claras. Renombrar 300 archivos, combinar reportes mensuales, transformar docenas de hojas de cálculo o descargar periódicamente un archivo público son buenos candidatos. Sin embargo, la pregunta avanzada no es “¿puedo automatizarlo?”, sino “¿qué tendría que ser verdad para que sea seguro automatizarlo?”

Antes de escribir código conviene medir la repetición. Si una operación manual consume 3 minutos y ocurre 20 veces por semana, se dedica aproximadamente una hora semanal a la misma secuencia. Esa observación convierte una molestia vaga en un problema cuantificable y permite comparar el tiempo que costará diseñar, probar y mantener la automatización.

52 h
💫 El dato que cambia todo: una tarea de solo 3 minutos, repetida 20 veces cada semana durante 52 semanas, consume alrededor de 52 horas al año. El tamaño de una automatización no se mide solo por la duración de una ejecución, sino por la frecuencia acumulada.

Una automatización madura debe pensar en idempotencia: cuando sea posible, ejecutar dos veces el mismo proceso no debería duplicar resultados ni destruir información. Imagine un script que ordena fotografías familiares según fecha. Si la primera ejecución mueve 2,000 archivos correctamente pero la segunda vuelve a renombrarlos de manera incompatible, no existe todavía una automatización confiable; existe una acción rápida con efectos difíciles de revertir.

También hacen falta trazabilidad y recuperación. Un script que modifica documentos debería registrar qué cambió y conservar una estrategia de respaldo cuando el costo del error sea relevante. En la vida cotidiana esto puede aplicarse a archivos personales, presupuestos, registros de asociaciones civiles o conjuntos de datos comunitarios. Automatizar bien significa reducir trabajo repetitivo sin volver invisible la responsabilidad.

from pathlib import Path

carpeta = Path("reportes")

for archivo in carpeta.glob("*.csv"):
    destino = archivo.with_name(archivo.stem.lower().replace(" ", "_") + ".csv")

    if destino != archivo and not destino.exists():
        archivo.rename(destino)
        print(f"Renombrado: {archivo.name} -> {destino.name}")
03

Scraping básico: obtener datos de la web sin confundir acceso con permiso

El web scraping transforma contenido de páginas web en datos estructurados. Técnicamente puede ser tan simple como descargar HTML y localizar elementos mediante selectores. Conceptualmente es más complejo: una página fue diseñada para personas, no necesariamente como interfaz estable para programas. Por eso una modificación de clases CSS puede romper un extractor aunque el contenido siga siendo perfectamente visible para un lector humano.

El Robots Exclusion Protocol fue estandarizado formalmente como RFC 9309 en 2022, aunque sus antecedentes se remontan a 1994. El archivo robots.txt comunica reglas para clientes automatizados, pero el propio estándar aclara que dichas reglas no constituyen un mecanismo de autorización (Koster et al., 2022). Esto significa que consultar robots.txt es una parte del análisis responsable, no una licencia universal para recolectar cualquier dato.

⚠️ Que algo sea visible no significa que deba recolectarse
Antes de automatizar una extracción revise términos del sitio, robots.txt, existencia de API o descarga oficial, frecuencia de solicitudes, naturaleza de los datos y posibles implicaciones de privacidad. Nunca convierta el scraping en una técnica para evadir controles de acceso.

Para una aplicación ciudadana, la jerarquía razonable suele ser: primero buscar una descarga oficial en CSV o JSON; después una API pública; y solo cuando no exista una interfaz estructurada considerar extraer información de una página abierta y estable. En México, numerosos conjuntos públicos se distribuyen como archivos o servicios de datos; usar esos canales suele producir soluciones más reproducibles y menos frágiles que depender de la presentación visual de una página.

También importa la carga generada. Un ser humano puede abrir una página tres veces en una mañana; un bucle mal diseñado puede solicitarla cientos de veces en pocos segundos. Guardar respuestas localmente, imponer pausas y recuperar únicamente lo necesario no es solo cortesía técnica: es reconocer que el servidor es un recurso compartido. La automatización amplifica tanto las buenas decisiones como las malas.

04

Análisis con pandas: transformar una tabla en una pregunta verificable

pandas apareció para resolver un problema concreto: trabajar en Python con datos tabulares de una manera suficientemente expresiva para análisis reales. Wes McKinney presentó en 2010 las estructuras que dieron forma al proyecto, entre ellas el DataFrame, hoy central en el ecosistema de análisis con Python (McKinney, 2010). Un DataFrame no debe entenderse como una “hoja de cálculo dentro de Python”, sino como una estructura sobre la que pueden declararse transformaciones reproducibles.

Suponga un archivo de 10,000 registros de precios, fechas y categorías. Abrirlo manualmente y aplicar filtros visuales puede funcionar una vez; escribir una cadena de transformaciones permite repetir exactamente el mismo criterio cuando lleguen otros 10,000 registros. La diferencia epistemológica es importante: un análisis programado deja rastros de cómo se pasó del dato bruto a la conclusión.

Filtrar pocas columnas Agrupar muchos registros Limpiar casos puntuales Reestructurar varias variables más estructura más agregación
Toca un cuadrante para relacionar la pregunta con una operación típica de pandas.

El verdadero riesgo aparece cuando una operación técnicamente válida responde a una pregunta distinta. Por ejemplo, dropna() puede eliminar automáticamente las filas con datos faltantes, pero ¿qué sucede si los valores ausentes se concentran precisamente en municipios con menor capacidad de registro? La limpieza dejaría de ser neutral. El código ejecutaría perfectamente una decisión metodológica discutible.

Por ello conviene adoptar un patrón de trabajo: inspeccionar, formular una hipótesis sobre la estructura, transformar, comparar conteos antes y después y validar algunos registros manualmente. En vez de imaginar que pandas “arregla” datos, es más preciso decir que permite hacer explícitas transformaciones. La persona analista continúa siendo responsable de justificar por qué esas transformaciones preservan el significado relevante.

import pandas as pd

df = pd.read_csv("consumo_agua.csv")

resumen = (
    df
    .dropna(subset=["municipio", "litros"])
    .query("litros >= 0")
    .groupby("municipio", as_index=False)
    .agg(
        consumo_medio=("litros", "mean"),
        registros=("litros", "size")
    )
    .sort_values("consumo_medio", ascending=False)
)

print(resumen.head())
🤔

Si una decisión de limpieza cambia quién aparece y quién desaparece del conjunto de datos, ¿sigue siendo solamente una decisión “técnica”?

05

Visualización con matplotlib: argumentar con una gráfica sin deformar la evidencia

Visualizar datos no es la etapa decorativa del análisis. Es una operación de selección: decidir qué variable ocupa un eje, qué escala se utiliza, qué observaciones se agrupan y qué detalles se vuelven visibles. John D. Hunter presentó matplotlib en 2007 como un entorno de gráficos 2D para computación científica en Python (Hunter, 2007). Desde entonces, el ecosistema creció, pero la pregunta fundamental sigue siendo la misma: ¿qué relación queremos que el lector pueda inspeccionar?

Imagine un registro mensual de contaminación atmosférica. Una línea puede mostrar evolución temporal; barras pueden comparar alcaldías o municipios; un diagrama de dispersión puede explorar la relación entre dos variables. El error frecuente consiste en elegir una gráfica porque “se ve bien”. En análisis aplicado, la geometría debe corresponder a la pregunta. Una serie temporal con meses desordenados, por ejemplo, puede producir una imagen técnicamente correcta y conceptualmente absurda.

También importan escalas y contexto. Recortar el eje vertical de una gráfica de barras puede exagerar diferencias pequeñas; mezclar unidades en el mismo eje puede sugerir comparabilidad donde no existe; y un promedio sin indicar cantidad de observaciones puede esconder que una categoría tiene 500 registros y otra apenas 4. Una gráfica responsable no elimina toda complejidad: elimina la complejidad que no ayuda a responder la pregunta y conserva la que podría cambiar la interpretación.

En la vida pública esto importa especialmente. Gráficas de inflación, agua, contaminación, movilidad, presupuesto o violencia circulan como argumentos, no solo como ilustraciones. Saber producirlas permite también leerlas críticamente. Quien entiende cómo se construye un eje, una agregación o una serie puede preguntar qué quedó fuera del encuadre y qué transformación precedió al resultado.

import matplotlib.pyplot as plt

fig, ax = plt.subplots(figsize=(8, 4.5))

ax.bar(
    resumen["municipio"],
    resumen["consumo_medio"]
)

ax.set_title("Consumo medio registrado por municipio")
ax.set_xlabel("Municipio")
ax.set_ylabel("Litros")
ax.tick_params(axis="x", rotation=45)

fig.tight_layout()
plt.show()
Cierre

Conclusión

El objetivo de esta ficha era integrar herramientas, no acumular comandos. Python aporta una estructura para expresar reglas; la automatización convierte esas reglas en procesos repetibles; el scraping plantea el problema de obtener información desde sistemas que no necesariamente fueron diseñados como fuentes de datos; pandas vuelve explícitas las transformaciones; y matplotlib transforma resultados en representaciones que otras personas pueden inspeccionar. La competencia aparece cuando esas cinco capas forman un razonamiento continuo.

El punto crítico es que cada capa introduce decisiones. Una función puede modelar mal un fenómeno; una automatización puede repetir un error; una extracción puede ignorar límites; una limpieza puede borrar casos significativos; una gráfica puede exagerar una diferencia. Programar aplicada y críticamente significa construir la solución y, al mismo tiempo, construir mecanismos para desconfiar de ella. Esa capacidad de revisión es lo que convierte al código en una herramienta de conocimiento y no solo de velocidad.

Por eso el siguiente paso no consiste necesariamente en aprender otra biblioteca. Puede consistir en diseñar mejores pruebas, estudiar bases de datos, aprender estadística, comprender APIs, incorporar control de versiones o investigar cómo las decisiones algorítmicas distribuyen beneficios y riesgos. Cuanto más capaz se vuelve una persona de automatizar el mundo, más importante se vuelve preguntar qué mundo está representando su código.

Referencias

  • Hunter, J. D. (2007). Matplotlib: A 2D graphics environment. Computing in Science & Engineering, 9(3), 90–95. https://doi.org/10.1109/MCSE.2007.55
  • Koster, M., Illyes, G., Zeller, H., & Sassman, L. (2022). RFC 9309: Robots Exclusion Protocol. Internet Engineering Task Force. https://doi.org/10.17487/RFC9309
  • McKinney, W. (2010). Data structures for statistical computing in Python. Proceedings of the 9th Python in Science Conference, 56–61. https://doi.org/10.25080/Majora-92bf1922-00a
  • Python Software Foundation. (2026). Python 3.14.7 documentation. https://docs.python.org/3.14/
  • Wing, J. M. (2006). Computational thinking. Communications of the ACM, 49(3), 33–35. https://doi.org/10.1145/1118178.1118215

🔭 Para seguir aprendiendo

  • ¿Qué problemas de una comunidad deberían deliberadamente permanecer fuera de una automatización aunque técnicamente pudieran programarse?
  • ¿Cómo cambia la responsabilidad de una decisión cuando un proceso que antes ejecutaba una persona pasa a repetirse automáticamente miles de veces?
  • ¿Qué métodos permitirían auditar un análisis de datos de interés público para que otra persona pueda reconstruir no solo el código, sino también las decisiones metodológicas?
Ahora tú

Actividad de aprendizaje autónoma

Proyecto: construya un miniobservatorio de datos públicos. El propósito es producir un pequeño flujo reproducible que parta de una pregunta real y termine en una gráfica argumentada. Puede trabajar con movilidad, medio ambiente, precios, presupuesto público, agua, población u otro tema para el que encuentre datos legítimamente accesibles en México o América Latina.

Antes de empezar el proyecto, complete estas cuatro relaciones conceptuales. No buscan medir memoria de sintaxis: buscan comprobar que las piezas del flujo están conectadas correctamente.

Ahora construya el producto:

  1. Formule una pregunta concreta que pueda responderse con datos. Evite “analizar la contaminación”; prefiera algo como “¿cómo cambió el promedio mensual de determinado indicador durante un periodo definido?”.
  2. Localice una fuente pública y documente su procedencia. Prefiera CSV, JSON o API oficial. Si recurre a una página web, revise primero las condiciones aplicables, robots.txt y si existe una alternativa estructurada.
  3. Escriba un script en Python que separe al menos tres responsabilidades mediante funciones: carga u obtención, transformación y producción del resultado.
  4. Cargue los datos en pandas. Registre cuántas filas existen antes y después de limpiar, qué valores faltantes encontró y qué criterio utilizó para conservar o descartar observaciones.
  5. Produzca con matplotlib una gráfica cuya geometría responda directamente a la pregunta. Añada título, unidades y etiquetas suficientes para que pueda interpretarse sin leer el código.
  6. Ejecute nuevamente el flujo desde el inicio. Compruebe que puede reproducir la salida sin hacer correcciones manuales ocultas entre un paso y otro.

Evidencia de logro: conserve en una carpeta el script o cuaderno ejecutable, el archivo de datos utilizado o la instrucción necesaria para recuperarlo, la gráfica final y un archivo breve de notas que explique fuente, transformaciones y limitaciones.

Criterio de éxito: otra persona debería poder identificar la pregunta inicial, ejecutar el flujo con las mismas entradas, comprender qué transformaciones hizo pandas, rastrear la procedencia del dato y explicar por qué la gráfica elegida responde —o no responde— a la pregunta.

Desafío avanzado: introduzca deliberadamente un caso problemático —un valor ausente, un duplicado o una categoría escrita de dos maneras— y compruebe si su proceso lo detecta. Después explique si decidió corregirlo, conservarlo o excluirlo y por qué.

Reflexión final: ¿qué decisión de todo su flujo parecía al principio puramente técnica, pero terminó teniendo consecuencias sobre la interpretación del problema real?