Introducción a Python

A: IndexError — la lista tiene 3 elementos (índices 0, 1, 2) y se intenta acceder al índice 5.

B: ValueError — el tipo es correcto (str), pero "3.14" no es un entero válido. Habría que hacer int(float("3.14")).

C: AttributeError — int no tiene el método upper(), que es de str.

D: KeyError — la clave "b" no existe en el diccionario.

E: TypeError — len() requiere un objeto con longitud (lista, string, dict...) y 42 es un entero que no la tiene.

KeyboardInterrupt y SystemExit heredan directamente de BaseException — no de Exception. Esto es deliberado: son señales del sistema que indican que el programa debe terminar. Si heredaran de Exception, un except Exception genérico las capturaría y el programa no podría terminar con Ctrl+C ni con sys.exit(). La consecuencia práctica: nunca uses except BaseException — siempre except Exception como mínimo.

TypeError: el tipo del argumento es incorrecto — int() no puede operar sobre ese tipo.

ValueError: el tipo es correcto — str es un tipo válido para int() — pero el valor concreto no puede convertirse.

# TypeError — tipo incorrecto
try:
    int([1, 2, 3])   # lista — no es un tipo válido
except TypeError as e:
    print(f"TypeError: {e}")

# ValueError — tipo correcto, valor incorrecto
try:
    int("abc")   # str es válido pero "abc" no es un entero
except ValueError as e:
    print(f"ValueError: {e}")

KeyError: 'ventas'. El DataFrame tiene una columna llamada "Ventas" con V mayúscula — Python y pandas son case-sensitive. df["ventas"] con v minúscula no existe. La corrección: df["Ventas"].sum() o normalizar los nombres al crear el DataFrame con str.lower().

Tipo de error: KeyError. Línea donde ocurrió: línea 6 en normalizar. La causa raíz: el DataFrame no tiene una columna llamada "ventas" — probablemente se llama distinto, por ejemplo "Ventas" con V mayúscula. Cómo corregirlo: verificar con df.columns cómo se llaman las columnas reales y ajustar el nombre en normalizar — o normalizar los nombres al inicio del pipeline con df.columns.str.lower().

Los tracebacks de pandas son largos porque las operaciones de pandas pasan por muchas capas internas — validación de tipos, selección de implementación, operaciones numpy. Cada una añade frames al stack. La causa del error siempre está en el código del usuario — las líneas que apuntan a ficheros dentro de site-packages/pandas/ o numpy/ son las capas internas y generalmente no son la causa. Busca las líneas que apuntan a tus propios ficheros.

e.__cause__ es el error original que causó el error actual — aparece cuando se usa raise NuevoError from error_original. Python preserva la cadena de causalidad. El mensaje "During handling of the above exception, another exception occurred" aparece cuando ocurre un segundo error mientras se estaba manejando el primero — por ejemplo dentro de un bloque except. Es una señal de que el código de manejo de errores tiene también un error.

ZeroDivisionError: division by zero. analizar llama a media con una lista vacía. sum([]) devuelve 0 y len([]) devuelve 0, así que se intenta calcular 0 / 0.

Traceback (most recent call last):
  File "script.py", line 8, in <module>
    analizar("ventas.csv")
  File "script.py", line 6, in analizar
    return media(datos)
  File "script.py", line 2, in media
    return sum(datos) / len(datos)
ZeroDivisionError: division by zero

La causa raíz: datos = [] en analizar — la función no carga ningún dato del fichero, solo inicializa una lista vacía y la pasa directamente.

test(2): el try ejecuta sin error, imprime resultado: 5.0. El else se ejecuta — imprime sin error. El finally siempre — imprime finally.

test(0): el try lanza ZeroDivisionError — el print de resultado no se ejecuta. El except captura el error e imprime división por cero. El else no se ejecuta — hubo error. El finally siempre — imprime finally.

El except: sin tipo captura absolutamente todo — incluyendo KeyboardInterrupt, SystemExit y MemoryError. Podría estar silenciando que el fichero no existe, que tiene un formato incorrecto, que no hay memoria suficiente, o que el usuario presionó Ctrl+C. El programa devuelve None silenciosamente en todos estos casos. La corrección:

def cargar_csv(ruta):
    try:
        import pandas as pd
        df = pd.read_csv(ruta)
        return df
    except FileNotFoundError:
        print(f"Fichero no encontrado: {ruta}")
        return None
    except Exception as e:
        print(f"Error inesperado cargando {ruta}: {e}")
        return None

else tiene sentido cuando quieres distinguir claramente entre el código que puede fallar y el código que solo se ejecuta si tuvo éxito. Es mejor que poner el código de éxito al final del try porque si ese código adicional también lanza una excepción, el except la capturaría — aunque el error no tenga nada que ver con la operación que querías proteger. Con else el código de éxito no está protegido por el except — los errores ahí se propagan normalmente.

def leer_entero(mensaje="Introduce un entero: "):
    intentos = 0
    while True:
        try:
            intentos += 1
            valor = int(input(mensaje))
            return valor
        except ValueError:
            print("Eso no es un entero. Inténtalo de nuevo.")
        finally:
            print(f"Intentos realizados hasta ahora: {intentos}")

# n = leer_entero("¿Cuántas filas quieres ver? ")

raise ValueError("mensaje") lanza un error nuevo sin conexión con ningún error anterior. Si se produce dentro de un except, Python mostrará ambos errores con el mensaje "During handling of the above exception" — conexión implícita.

raise ValueError("mensaje") from e establece explícitamente que el nuevo error fue causado por e. El traceback muestra la cadena completa de forma clara. from None suprime el error original cuando no aporta información útil. Usa from e cuando el error original ayuda a entender el nuevo, y from None cuando solo añade ruido.

class NotaInvalidaError(Exception):
    """Error cuando una nota está fuera del rango [0, 10]."""
    def __init__(self, nota):
        self.nota = nota
        super().__init__(
            f"Nota inválida: {nota}. "
            f"Debe estar entre 0 y 10."
        )

def registrar_nota(nota):
    """Registra una nota validando que esté en [0, 10]."""
    if not isinstance(nota, (int, float)):
        raise TypeError(f"La nota debe ser numérica, no {type(nota).__name__}")
    if not (0 <= nota <= 10):
        raise NotaInvalidaError(nota)
    print(f"Nota {nota} registrada correctamente")
    return nota

try:
    registrar_nota(8.5)   # ✓
    registrar_nota(11)    # NotaInvalidaError
except NotaInvalidaError as e:
    print(f"Error: {e}")
except TypeError as e:
    print(f"TypeError: {e}")

Sin with, si ocurre un error después de open() y antes de f.close(), el fichero queda abierto indefinidamente — hasta que el proceso termina o el garbage collector lo cierra. En sistemas con muchos ficheros abiertos simultáneamente esto puede agotar los descriptores de fichero del sistema operativo. with garantiza el cierre en cualquier caso — es equivalente a un try/finally con f.close() en el finally.

Tres problemas: except: sin tipo captura todo incluyendo KeyboardInterrupt. No hay logging — el error desaparece silenciosamente. Devuelve None, None sin que el llamante sepa qué falló.

def analizar(ruta, columna):
    try:
        import pandas as pd
        df = pd.read_csv(ruta)
        media = df[columna].mean()
        maximo = df[columna].max()
        print(f"media: {media:.2f}, máximo: {maximo}")
        return media, maximo
    except FileNotFoundError:
        print(f"Fichero no encontrado: {ruta}")
        return None, None
    except KeyError:
        print(f"Columna '{columna}' no existe")
        return None, None
    except Exception as e:
        print(f"Error inesperado: {type(e).__name__}: {e}")
        return None, None

assert es para verificaciones de desarrollo — suposiciones sobre el estado interno del programa que deberían ser siempre ciertas. Se pueden desactivar en producción con python -O. No deben usarse para validar datos de entrada del usuario porque en producción estarían desactivados.

if not condición: raise ValueError es para validaciones que deben estar activas siempre — en producción y en desarrollo. Es la herramienta correcta para validar argumentos de funciones públicas y datos de entrada.

def procesar(df, debug=False):
    resultado = df.groupby("categoria")["ventas"].sum()
    if debug:
        print(
            f"[procesar] resultado groupby:\n"
            f"  type={type(resultado).__name__}\n"
            f"  shape={resultado.shape}\n"
            f"  dtype={resultado.dtype}\n"
            f"  valores:\n{resultado}"
        )
    return resultado

breakpoint() pausa la ejecución y abre el prompt interactivo de pdb donde puedes inspeccionar el estado del programa. El mejor lugar para ponerlo es dentro de calcular_total justo después de calcular precios_desc — para ver qué elementos se procesaron realmente:

def calcular_total(precios, descuentos):
    precios_desc = [p * (1 - d)
                    for p, d in zip(precios, descuentos)]
    # breakpoint()  ← aquí verías que precios_desc
    # tiene solo 2 elementos — zip se detiene
    # en el más corto — descuentos tiene 2
    total = sum(precios_desc)
    return total

El problema es que zip se detiene en el iterable más corto — descuentos tiene solo 2 elementos, así que el precio de 150 no se procesa.

El patrón debug=False es mejor porque no modifica el código entre sesiones de debugging — no hay riesgo de olvidar quitar un print antes de pasar a producción. Se activa y desactiva con un parámetro. Documenta explícitamente que la función tiene modo de debugging. Permite activar el debugging en producción de forma controlada sin modificar el código fuente.

El problema está en el cálculo de pct_cambio. La fórmula divide la diferencia entre el valor actual en lugar del anterior. Para febrero: 100 / 200 * 100 = 50% — pero debería ser 100 / 100 * 100 = 100%.

# Corrección — dividir por el valor anterior
df["pct_cambio"] = df["ventas"].pct_change() * 100
# pct_change() calcula (actual - anterior) / anterior
print(df)
# feb: 100.0% — correcto
# mar: -25.0% — (150-200)/200 = -25%

Es un error silencioso porque el merge no lanza ninguna excepción — simplemente produce un resultado con más filas de las esperadas (4, no 5) porque es un inner join: los clientes 4 y 5 no tienen pedidos y desaparecen. Además el cliente 1 aparece dos veces porque tiene dos pedidos.

Cómo detectarlo: comparar len(clientes) con len(resultado) y verificar que todos los ids están presentes. Cómo corregirlo:

# left join — conserva todos los clientes
resultado = pd.merge(
    clientes, pedidos,
    left_on="id", right_on="cliente_id",
    how="left"
)
print(f"resultado con left join: {len(resultado)} filas")
# Los clientes sin pedidos tendrán NaN en importe

# Verificar que no perdemos clientes
assert set(resultado["id"]) == set(clientes["id"]), \
    "El merge perdió clientes"

Un error que lanza excepción detiene el programa e indica exactamente dónde está el problema. Es molesto pero fácil de localizar.

Un error silencioso es más peligroso en análisis de datos porque el código termina con éxito, produce resultados, genera gráficos y tablas — pero todo está mal. Una decisión tomada con datos incorrectos es peor que no tener ningún resultado. El único antídoto es verificar sistemáticamente los resultados intermedios contra cálculos manuales.

resultado = (
    df
    .pipe(inspeccionar_df, "original")      # 5 filas
    .dropna()
    .pipe(inspeccionar_df, "tras dropna")   # 3 filas — pierde None en ventas y precio
    .query("ventas > 100")
    .pipe(inspeccionar_df, "tras query")    # 2 filas — pierde ventas=50
    .assign(ingreso=lambda d: d["ventas"] * d["precio"])
    .pipe(inspeccionar_df, "final")
)
# Conclusión: dropna elimina 2 filas (nulos en ventas y precio)
# query elimina 1 fila más (ventas=50)
# quedan 2 filas — correcto dado los datos de entrada

El nivel del logger es el primer filtro — los mensajes por debajo de ese nivel se descartan inmediatamente sin llegar a ningún handler. El nivel del handler es el segundo filtro — de los mensajes que pasan el filtro del logger, el handler solo procesa los que están por encima de su propio nivel.

Si el logger tiene nivel DEBUG y el handler tiene nivel WARNING: el logger deja pasar todos los mensajes, pero el handler solo muestra los de nivel WARNING o superior. Los mensajes DEBUG e INFO llegan al handler pero este los ignora.

logging.info() usa el logger raíz — un objeto global compartido por todos los módulos del programa. En un proyecto con varios módulos todos escriben en el mismo lugar sin indicar de dónde viene cada mensaje.

getLogger(__name__) crea un logger con el nombre del módulo actual. Cada mensaje indica su origen exacto — analisis.limpieza, analisis.pipeline. Permite configurar el nivel de cada módulo de forma independiente y filtrar mensajes por módulo en los logs.

import logging

logger = logging.getLogger("ventas")
logger.setLevel(logging.DEBUG)

if logger.hasHandlers():
    logger.handlers.clear()

fmt = logging.Formatter(
    "%(asctime)s | %(levelname)-8s | %(message)s",
    datefmt="%H:%M:%S"
)

# Consola — solo WARNING+
ch = logging.StreamHandler()
ch.setLevel(logging.WARNING)
ch.setFormatter(fmt)
logger.addHandler(ch)

# Fichero — todo desde DEBUG
fh = logging.FileHandler("ventas.log", encoding="utf-8")
fh.setLevel(logging.DEBUG)
fh.setFormatter(fmt)
logger.addHandler(fh)

# Prueba
logger.debug("shape: (500, 4)")          # solo fichero
logger.info("Datos cargados")            # solo fichero
logger.warning("5 nulos encontrados")    # consola + fichero
logger.error("Columna no encontrada")    # consola + fichero

Pipeline procesó 1000 filas → INFO: progreso normal, útil en producción para confirmar que el proceso avanza.

5 valores nulos en precio → WARNING: algo inesperado que el programa maneja pero que merece atención.

Fichero no existe → ERROR: una operación falló — el fichero no se cargó — pero quizás el programa puede continuar con otros datos.

Media calculada 142.5 → DEBUG: información detallada solo útil durante el desarrollo — no necesaria en producción.

Conexión a BD fallida → CRITICAL: el programa no puede continuar su función principal — es un fallo irrecuperable.

logger.error("mensaje") registra el mensaje con nivel ERROR — sin información adicional sobre el error que pudo haberlo causado.

logger.exception("mensaje") registra el mensaje con nivel ERROR y añade automáticamente el traceback completo del error activo en el bloque except. Solo funciona dentro de un bloque except — fuera de él no hay traceback que añadir. Usa error() para errores esperados y manejados — usa exception() para errores inesperados donde el traceback es necesario para entender qué falló.

func.__module__ es el nombre del módulo donde está definida la función decorada — no el módulo donde está el decorador. Si la función cargar_csv está en analisis.datos, el logger se llama analisis.datos — los mensajes identifican exactamente de qué módulo vienen. Si usara un logger fijo todos los mensajes de todas las funciones decoradas irían al mismo logger sin distinción de origen.

import logging
import glob
import pandas as pd

logger = logging.getLogger(__name__)

def procesar_ficheros(carpeta):
    ficheros = glob.glob(f"{carpeta}/*.csv")

    logger.info(f"Encontrados {len(ficheros)} ficheros en {carpeta}")

    if not ficheros:
        logger.warning(f"No hay ficheros CSV en: {carpeta}")
        return []

    resultados = []
    for f in ficheros:
        try:
            df = pd.read_csv(f)
            logger.info(f"Cargado '{f}': {df.shape}")
            logger.debug(f"  dtypes: {df.dtypes.to_dict()}")
            resultados.append(df)
        except Exception:
            logger.exception(f"Error cargando '{f}'")

    logger.info(
        f"Procesados {len(resultados)}/{len(ficheros)} ficheros"
    )
    return resultados

Un FileHandler normal escribe en un fichero que crece indefinidamente — en un proceso que lleva días o semanas ejecutando, el fichero de log puede llegar a ocupar gigabytes.

Un RotatingFileHandler limita el tamaño del fichero. Cuando el fichero alcanza maxBytes — 5 MB en el ejemplo — lo renombra a app.log.1 y empieza uno nuevo. backupCount=3 significa que mantiene hasta 3 ficheros de backup: app.log, app.log.1, app.log.2, app.log.3. Cuando habría un cuarto, elimina el más antiguo. El espacio en disco queda acotado a maxBytes × (backupCount + 1) — en el ejemplo, 20 MB máximo.