Introducción a Python

# A
triple = lambda x: x * 3

# B
mayor = lambda x, y: x if x > y else y

# C
def negativo(x):
    return -x

# D
def en_rango(x, a, b):
    return a <= x <= b

f1, f2 y f4 son correctas — simples y legibles. f3 es problemática — dos ternarios anidados en una lambda son muy difíciles de leer y de verificar. Debería ser un def con if/elif/else.

Ordenar por campo → lambda: key=lambda d: d["campo"] — un solo uso, una expresión.

Calcular IVA en diez sitios → def calcular_iva(precio): se reutiliza — merece nombre.

Transformar columna DataFrame → depende: si es simple, lambda row: ... en apply. Si es compleja, def.

Validar email con regex → def: necesita importar módulo, manejar excepciones, documentar el patrón. Demasiado complejo para lambda.

Asignar una lambda a una variable derrota su propósito porque la ventaja de lambda es precisamente no crear un nombre. Si la asignas a f, es exactamente igual que un def f — pero sin docstring, sin anotaciones y con peor legibilidad.

Tiene sentido hacerlo en prototipos rápidos o en sesiones interactivas donde no merece la pena escribir un def completo. En código de producción — o en código que leerán otros — siempre es mejor def.

sorted(datos, key=lambda x: x[1]) → por ventas ascendente: [('pera', 80), ('fresa', 95), ('manzana', 150), ('kiwi', 200)]. sorted(datos, key=lambda x: x[0]) → alfabético por nombre: [('fresa', 95), ('kiwi', 200), ('manzana', 150), ('pera', 80)]. filter(lambda x: x[1] > 100, datos) → ventas mayores de 100: [('manzana', 150), ('kiwi', 200)]. map(lambda x: (x[0], x[1]*1.10), datos) → ventas con bonus: [('manzana', 165.0), ('pera', 88.0), ('kiwi', 220.0), ('fresa', 104.5)].

calcular_margen es simple — puede ser lambda. es_rentable también — puede ser lambda.

df["margen"] = df.apply(
    lambda fila: fila["ventas"] - fila["costes"],
    axis=1
)
df["rentable"] = df["margen"].map(
    lambda m: "sí" if m > 50 else "no"
)

Pero la versión con def también es válida — los nombres calcular_margen y es_rentable hacen el código más legible y reutilizable. Ninguna versión es estrictamente mejor — depende del contexto.

El código es correcto — filtra productos con stock y los ordena por valor total (precio × stock) descendente. Resultado: [C: 15×3=45, A: 10×5=50] — espera, A tiene mayor valor así que: [A (50), C (45)].

Es legible — cada lambda hace una cosa clara. La única mejora posible sería extraer el criterio de ordenamiento si se reutiliza:

def valor_total(p):
    return p["precio"] * p["stock"]

resultado = sorted(
    filter(lambda p: p["stock"] > 0, productos),
    key=valor_total,
    reverse=True
)

La versión A usa serie.map() — opera sobre cada valor de una sola columna. Es más eficiente y más clara cuando la lógica depende de una sola columna.

La versión B usa df.apply(axis=1) — opera sobre cada fila completa. Necesaria cuando la lógica depende de varias columnas. Para este caso es innecesaria y más lenta — accede a la fila entera para leer solo una columna.

Imprime en orden: antes, calculando 3 + 4, después, resultado: 7. El wrapper ejecuta print("antes"), llama a calcular(3, 4) que imprime su mensaje y devuelve 7, luego print("después"), y finalmente devuelve 7 a quien llamó.

Si el wrapper no devuelve resultado, devuelve None implícitamente — el valor de retorno de la función original se pierde. El llamante recibe None en lugar del resultado esperado. Es uno de los errores más frecuentes al escribir decoradores a mano y el más difícil de detectar porque no produce un error — solo un resultado incorrecto.

def log_llamada(func):
    def wrapper(*args, **kwargs):
        args_str = ', '.join(repr(a) for a in args)
        kwargs_str = ', '.join(
            f"{k}={repr(v)}" for k, v in kwargs.items()
        )
        todos = ', '.join(filter(None, [args_str, kwargs_str]))
        print(f"llamando {func.__name__}({todos})")
        return func(*args, **kwargs)
    return wrapper

@log_llamada
def calcular_precio(base, iva=0.21):
    return round(base * (1 + iva), 2)

print(calcular_precio(100))
print(calcular_precio(100, iva=0.10))

@medir_tiempo equivale a proceso_lento = medir_tiempo(proceso_lento) porque Python procesa el decorador exactamente así: llama a medir_tiempo con proceso_lento como argumento y reasigna el nombre proceso_lento al resultado — que es wrapper. Después de decorar, proceso_lento es de tipo function — concretamente el objeto wrapper. Su free variable es func — que contiene la función original proceso_lento.

funcion_a.__name__ → 'wrapper', funcion_a.__doc__ → None — sin wraps los atributos de la función original se pierden.

funcion_b.__name__ → 'funcion_b', funcion_b.__doc__ → 'Docstring de funcion_b.' — con @wraps(func) los atributos se copian del original al wrapper.

Dos problemas: falta return en la llamada a func(x) — el resultado de raiz_cuadrada se pierde y print(raiz_cuadrada(9)) imprime None. Y falta @wraps(func) — raiz_cuadrada.__name__ devuelve 'wrapper'.

from functools import wraps

def validar_positivo(func):
    @wraps(func)                          # ← añadir wraps
    def wrapper(x):
        if x < 0:
            raise ValueError(
                f"x debe ser positivo, recibido: {x}"
            )
        return func(x)                    # ← añadir return
    return wrapper

@validar_positivo
def raiz_cuadrada(x):
    """Calcula la raíz cuadrada de x."""
    return x ** 0.5

print(raiz_cuadrada(9))          # 3.0
print(raiz_cuadrada.__name__)    # 'raiz_cuadrada'

from functools import wraps
import time

def medir_tiempo(func):
    """Mide el tiempo de ejecución de func."""
    @wraps(func)
    def wrapper(*args, **kwargs):
        inicio = time.time()
        resultado = func(*args, **kwargs)
        duracion = time.time() - inicio
        print(f"[{func.__name__}] {duracion:.6f}s")
        return resultado
    return wrapper

@medir_tiempo
def calcular_media(datos):
    """Calcula la media de una lista de números."""
    return sum(datos) / len(datos)

print(calcular_media([1, 2, 3, 4, 5]))
print(calcular_media.__name__)   # 'calcular_media'
print(calcular_media.__doc__)    # 'Calcula la media...'

@wraps(func) es un decorador con parámetros — exactamente lo que veremos en el Bloque 3. wraps(func) devuelve un decorador configurado para copiar los atributos de func. Ese decorador se aplica a wrapper — la función interior. Es un decorador que decora el wrapper dentro de otro decorador — tres niveles de anidamiento que ya conocemos gracias a la Clase 6c.

sumar(3, 4): prefijo("RESULTADO") devuelve decorator, decorator(sumar) devuelve wrapper con texto="RESULTADO" y func=sumar como free variables. wrapper(3, 4) llama a sumar(3, 4) que devuelve 7, luego devuelve "RESULTADO: 7".

media([1,2,3,4,5]) → "MEDIA: 3.0".

sumar.__name__ → 'sumar' — @wraps preserva el nombre.

El wrapper de logger("DEBUG") tiene dos free variables: func — del segundo nivel, decorator — que es la función cargar_datos original, y nivel — del primer nivel, la fábrica logger — con valor "DEBUG". func viene del closure del decorador. nivel viene del closure de la fábrica. Dos capas de closure anidadas — exactamente la mecánica de la Clase 6c.

from functools import wraps

def cache_simple(func):
    cache = {}
    @wraps(func)
    def wrapper(*args):
        if args not in cache:
            cache[args] = func(*args)
        else:
            print(f"[cache] {func.__name__}{args}")
        return cache[args]
    return wrapper

@cache_simple
def calcular_cuadrado(n):
    print(f"calculando {n}²")
    return n ** 2

print(calcular_cuadrado(4))   # calculando 4² → 16
print(calcular_cuadrado(4))   # [cache] → 16
print(calcular_cuadrado(5))   # calculando 5² → 25

El uso A es correcto: @repetir(3) llama a repetir(3) que devuelve decorator, y luego decorator(f) devuelve wrapper. Tres niveles — funciona.

El uso B falla: @repetir sin paréntesis equivale a g = repetir(g). repetir espera recibir un entero como primer argumento — veces — pero recibe la función g. Luego intenta range(g) — TypeError.

Paso 1 — función original: func — la función decorada, guardada como free variable.

Paso 2 — qué añade: antes de llamar a func comprueba si los argumentos ya están en almacen. Si están, devuelve el resultado guardado sin llamar a func. Si no están, llama a func, guarda el resultado y lo devuelve. Es un caché simple basado en los argumentos.

Paso 3 — ¿está completo? No del todo: falta @wraps(func) — el nombre y el docstring de la función original se pierden. Por lo demás el mecanismo es correcto.

Orden de ejecución: d1 antes, d2 antes, d3 antes, función, d3 después, d2 después, d1 después.

La aplicación es de abajo a arriba — primero d3, luego d2, luego d1. La ejecución es de fuera a dentro en los "antes" y de dentro a fuera en los "después" — como una cebolla.

Para registrar todos los intentos incluyendo los fallidos hay que usar el orden A: @registrar sobre @validar. registrar es la capa exterior — ve la llamada antes de que validar pueda rechazarla. Así registra tanto las llamadas válidas como las inválidas.

La aplicación es de abajo a arriba: primero validar_rango(0, 100), luego logger("INFO"), luego medir_tiempo.

La ejecución al llamar a procesar(valor): primero medir_tiempo captura el tiempo de inicio, luego logger registra la llamada, luego validar_rango comprueba que valor está entre 0 y 100 — si no, lanza ValueError antes de llegar a la función original —, luego procesar calcula valor * 2, luego logger registra la finalización, luego medir_tiempo imprime la duración.

@lru_cache(maxsize=128) tiene tres niveles: la fábrica lru_cache recibe maxsize, el decorador recibe func, el wrapper recibe los argumentos de func. Las free variables del wrapper son func y el caché interno — un diccionario que asocia argumentos con resultados.

Los argumentos deben ser hashables porque el caché usa los argumentos como claves de un diccionario. Las listas no son hashables — no pueden ser claves — porque son mutables. Una lista podría cambiar después de usarse como clave, invalidando el caché. Las tuplas sí son hashables — por eso el ejemplo usa datos_tuple.

@property transforma el método en un descriptor — cuando Python ve c.area, en lugar de devolver el objeto método, lo llama automáticamente y devuelve su resultado. Los paréntesis no son necesarios porque el descriptor se encarga de la llamada. Es un decorador especial integrado en Python que cambia cómo el intérprete accede al atributo.

El orden tiene un problema: @logger("INFO") está en la capa más interior — registra la llamada después de que requiere_datos ya haya validado el DataFrame. Si el DataFrame está vacío, requiere_datos lanza excepción antes de que logger pueda registrar nada. Para auditoría completa, el logger debería estar en la capa más exterior.

El orden correcto para auditoría completa:

@logger("INFO")    # exterior — registra todo
@medir_tiempo     # mide la validación + cálculo
@requiere_datos   # interior — valida antes de calcular
def analizar_ventas(df, columna="ventas"):
    """Analiza las ventas de un DataFrame."""
    return df[columna].describe()

Los tres decoradores tienen @wraps, *args/**kwargs y return resultado — la estructura es correcta. Solo el orden necesita ajuste.

El patrón A con decorador es mejor cuando quieres medir el tiempo en todas las llamadas a calcular de forma permanente — en producción, en logging sistemático. La medición es transparente — el llamante no sabe que está ocurriendo.

El patrón B con llamada directa es mejor cuando quieres medir el tiempo de una llamada concreta — en debugging puntual, en comparaciones de rendimiento, en código desechable. La medición es explícita y no afecta al resto del código.