Introducción a Python

print(g) → algo como <function doble at 0x...> — el objeto función. print(g(5)) → 10 — resultado de ejecutarlo. print(g.__name__) → 'doble' — nombre original del objeto. print(g.__doc__) → 'Devuelve el doble de x.'. print(g is doble) → True — el mismo objeto. print(type(g)) → <class 'function'>.

f.__name__ devuelve 'square' porque __name__ es un atributo del objeto función — no del nombre de variable que apunta a él. El atributo __name__ se asigna al objeto cuando Python procesa el def square y nunca cambia. del square borra la variable del scope global pero no toca el objeto ni sus atributos. El objeto sabe su nombre original independientemente de cómo se acceda a él.

a = saludar asigna la función — type(a) es function. b = saludar("Ana") llama a la función y asigna el resultado — type(b) es str porque saludar devuelve un string. La distinción visual: sin paréntesis es el objeto, con paréntesis es la llamada.

Si las funciones no fueran objetos, la IA solo podría generar código imperativo — instrucciones una tras otra. No podría crear funciones que reciben otras funciones como parámetro, lo que eliminaría patrones enteros de código como map, filter, sorted(key=...), df.apply() o los decoradores. El código generado sería mucho más repetitivo y mucho menos general.

Imprime 10, 15, 10. La lista contiene tres referencias a funciones — doblar, triplicar, doblar de nuevo. El bucle llama a cada una con argumento 5.

La ventaja del diccionario es que añadir una operación nueva no requiere modificar la lógica de selección — solo añadir una entrada al diccionario. El if/elif crece indefinidamente con cada operación nueva.

def doblar(x):    return x * 2
def triplicar(x): return x * 3
def cuadrado(x):  return x ** 2

operaciones = {
    "doblar":    doblar,
    "triplicar": triplicar,
    "cuadrado":  cuadrado,
}

def operar(x, operacion):
    return operaciones.get(operacion, lambda _: None)(x)

print(operar(5, "doblar"))      # 10
print(operar(5, "cuadrado"))    # 25

La ventaja del pipeline es que el orden de aplicación está explícito en la lista y se puede modificar, reordenar o extender sin tocar el código que lo aplica. Para añadir un paso nuevo:

def eliminar_duplicados(df):
    return df.drop_duplicates()

pipeline = [quitar_nulos, eliminar_duplicados,
            normalizar, renombrar]

El error es que sumar requiere dos argumentos pero el bucle la llama con uno solo — TypeError: sumar() missing 1 required positional argument: 'y'. len y abs aceptan un solo argumento, pero sumar no. Para mezclar funciones con distinto número de argumentos en una lista hay que asegurarse de que todas tienen la misma interfaz — o usar *args:

# Opción: funciones con la misma firma
def sumar_uno(x):
    return x + 1

operaciones = [sumar_uno, abs]
for op in operaciones:
    print(op(4))

aplicar(negativo, 3, 5) → (-3, -5). aplicar(abs, -4, -7) → (4, 7). aplicar(str, 42, 3.14) → ('42', '3.14'). En los tres casos aplicar llama a func con cada argumento y devuelve una tupla con los resultados. La función no sabe qué es func — solo la llama.

A y B no se pueden reescribir directamente con my_map porque las operaciones no son funciones de un solo argumento. La solución es definir funciones auxiliares o usar lambda — que veremos en la Clase 6d:

def con_iva(p):     return p * 1.21
def redondear(p):  return round(p, 2)
def etiquetar(p):  return f"{p:.2f}€"

print(my_map(con_iva,   precios))
print(my_map(redondear, precios))
print(my_map(etiquetar, precios))

Si pasas un entero, derivada_aproximada intentaría ejecutar f(x + h) donde f es el entero — TypeError: 'int' object is not callable. El entero no es callable — no tiene __call__. Es el mismo error que vimos en la Clase 6a con callable().

La versión A solo puede doblar — hace una cosa concreta y no se puede reutilizar para nada más. Si quieres triplicar, necesitas triplicar_lista. Si quieres elevar al cuadrado, necesitas cuadrar_lista. El código crece con cada operación nueva.

La versión B es general — funciona con cualquier transformación. Solo necesitas definir la operación concreta y pasarla como argumento. El código no crece con las operaciones nuevas.

list(map(len, palabras)) → [3, 4, 8, 3, 7] — longitud de cada palabra. list(filter(es_largo, palabras)) → ['estrella', 'montaña'] — palabras de más de 4 letras. sorted(palabras, key=len) → ['sol', 'mar', 'luna', 'montaña', 'estrella'] — orden ascendente por longitud. sorted(palabras, key=len, reverse=True) → ['estrella', 'montaña', 'luna', 'sol', 'mar'] — descendente.

map transforma — aplica una función a cada elemento y devuelve el resultado. La lista resultante tiene el mismo número de elementos que la original. filter selecciona — conserva solo los elementos que cumplen una condición. La lista resultante puede ser más corta que la original.

ventas = [150, 80, 200, 30, 120]

def es_alto(v):    return v > 100
def con_bonus(v):  return v * 1.10

# Ventas altas con bonus aplicado
resultado = list(map(con_bonus, filter(es_alto, ventas)))
print(resultado)   # [165.0, 220.0, 132.0]

key=len le dice a sorted que para comparar dos elementos, primero llame a len sobre cada uno y compare los resultados. Se pasa len sin paréntesis porque se pasa el objeto función — no su resultado. Con paréntesis, key=len() intentaría llamar a len() sin argumentos — lo que produce un TypeError porque len requiere un argumento.

El código es correcto pero apply con axis=1 es lento para esta operación porque itera fila a fila. La alternativa vectorizada es mucho más eficiente:

import numpy as np
df["categoria"] = np.where(
    df["ventas"] > 100, "alto", "bajo"
)

type(saludar) → <class 'function'>. saludar.__name__ → 'ingles' — el nombre de la función devuelta. saludar("Ana") → "Hello, Ana". crear_saludo("fr")("Bob") → "Bonjour, Bob" — dos paréntesis seguidos: el primero crea el saludo, el segundo lo llama. crear_saludo("de")("Carlos") → "Hola, Carlos" — "de" no existe en el dict, .get() devuelve el default español.

a = hablar_func(1): a es el objeto función gritar — tipo function. No se ha ejecutado aún. b = hablar_func(1)("hola"): primero se obtiene la función gritar, luego se llama con "hola". b es el string "HOLA" — tipo str.

La ventaja es que el formateador se configura una vez y se reutiliza muchas veces sin repetir el argumento de formato. Si el formato cambia, se cambia en un solo lugar. Pasar el formato en cada llamada es más flexible cuando el formato varía en cada llamada — pero más verboso y propenso a errores si siempre es el mismo.

def crear_clasificador(umbral):
    def clasificar(valor):
        return "alto" if valor > umbral else "bajo"
    return clasificar

# Dos clasificadores con distintos umbrales
clasificar_100 = crear_clasificador(100)
clasificar_500 = crear_clasificador(500)

print(clasificar_100(150))   # "alto"
print(clasificar_100(80))    # "bajo"
print(clasificar_500(150))   # "bajo"
print(clasificar_500(600))   # "alto"

Son el mismo objeto función en cuanto a código — el mismo cuerpo, la misma lógica. Lo que las diferencia es el valor de su free variable n: tablas3 tiene n = 3 guardado en su closure, tablas5 tiene n = 5. Cada vez que se llama tablas_mult se crea una función tablas nueva con su propia copia de n. El closure es lo que las hace independientes.

dto_20 tiene una free variable: ('porcentaje',) con valor 20.

validar_nota tiene dos free variables: ('maximo', 'minimo') — en orden alfabético — con valores 10 y 0. Cada parámetro de crear_validador que usa la función interior se convierte en una free variable del closure.

def crear_multiplicador_iva(tipo_iva):
    def aplicar_iva(precio):
        return round(precio * (1 + tipo_iva), 2)
    return aplicar_iva

iva_super = crear_multiplicador_iva(0.04)
iva_red   = crear_multiplicador_iva(0.10)
iva_gral  = crear_multiplicador_iva(0.21)

precios = [10, 50, 100]
print("Precio → IVA 4% → IVA 10% → IVA 21%")
for p in precios:
    print(f"{p:6}€ → {iva_super(p):7}€ "
          f"→ {iva_red(p):7}€ → {iva_gral(p):7}€")

Pasar los límites cada vez es más flexible pero más verboso y más propenso a errores — si los límites cambian hay que cambiarlos en cada llamada. La fábrica es claramente mejor cuando el mismo validador se usa muchas veces con los mismos límites: en un pipeline de datos, en la validación de un formulario o cuando se pasa el validador como argumento a otra función.

a no es un closure — no tiene free variables. a.__closure__ es None.

b = hacer_b(5) es un closure — usa n del scope enclosing. b.__closure__ contiene 5.

c = hacer_c(5) no es un closure — aunque viene de una función anidada, no usa ninguna variable del scope exterior. c.__closure__ es None. La existencia del closure depende de si hay free variables — no de si la función está anidada.

contador(100) imprime "Creando contador desde 100". inc() → 101. inc() → 102. inc(10) → 112. inc(-5) → 107. inc() → 108. El estado persiste entre llamadas porque inicio vive en el closure — no se reinicia en cada llamada.

La versión A no produce closure — inner_a se llama directamente y muere con outer_a. No hay objeto que sobreviva con las free variables.

La versión B produce closure — inner_b se devuelve sin llamar y f la referencia en el scope global. El objeto sobrevive con x = 10 en su closure. Ambas imprimen 10 pero solo B crea un closure.

registrar tiene tres free variables: nombre, total y transacciones.

transacciones no necesita nonlocal porque no se reasigna — se muta. transacciones.append() modifica el objeto lista que ya existe en el heap sin crear una referencia nueva. Python no necesita saber que la variable cambió porque la variable sigue apuntando al mismo objeto.

total sí necesita nonlocal porque total += cantidad es una asignación — total = total + cantidad — que crea una nueva referencia. Sin nonlocal, Python trataría total como variable local y lanzaría UnboundLocalError.

La free variable de lista_medida es func — que contiene el objeto función calcular_lista.

wrapper usa *args y **kwargs para ser compatible con cualquier función que se le pase — independientemente de cuántos parámetros tenga. Si usara parámetros fijos como wrapper(n), solo funcionaría con funciones que reciben exactamente un argumento posicional. Con *args, **kwargs funciona con cualquier firma.

class Acumulador:
    def __init__(self, nombre):
        self.nombre = nombre
        self.total = 0
        self.transacciones = []

    def registrar(self, cantidad, concepto="venta"):
        self.total += cantidad
        self.transacciones.append({
            "concepto": concepto,
            "cantidad": cantidad,
            "total":    self.total
        })
        print(f"[{self.nombre}] {concepto}: "
              f"+{cantidad}€ → total: {self.total}€")
        return self.total

tienda = Acumulador("Tienda A")
tienda.registrar(150)
tienda.registrar(80, "devolución")

La versión clase es más legible cuando hay múltiples atributos y métodos. La versión closure es más compacta cuando el estado es simple. Para este ejemplo con nombre, total y transacciones, la clase empieza a ganar en claridad.

@medir_tiempo equivale a saludar = medir_tiempo(saludar). medir_tiempo recibe la función saludar, crea wrapper con func = saludar como free variable y lo devuelve. saludar ahora apunta a wrapper.

Al llamar saludar("Ana"): se ejecuta wrapper("Ana"), que mide el tiempo, llama a la saludar original con "Ana" y devuelve el resultado. Imprime el tiempo transcurrido, luego "Hola, Ana", luego 'wrapper' — porque saludar.__name__ ahora es el nombre de wrapper.

def contar_llamadas(func):
    contador = [0]   # lista para poder mutar sin nonlocal

    def wrapper(*args, **kwargs):
        contador[0] += 1
        print(f"{func.__name__} llamada {contador[0]} vez/veces")
        return func(*args, **kwargs)
    return wrapper

@contar_llamadas
def saludar(nombre):
    return f"Hola, {nombre}"

print(saludar("Ana"))
print(saludar("Bob"))
print(saludar("Carlos"))

f1 es pura — mismo input siempre mismo output, sin efectos laterales.

f2 no es pura — modifica la lista de entrada con .sort(). El mismo input puede producir el mismo output pero el efecto lateral — modificar la lista — la hace impura.

f3 no es pura — dado el mismo input produce outputs distintos en cada llamada porque usa random.random().

f4 es pura — produce una lista nueva sin modificar la original. Mismo input → mismo output, sin efectos laterales.

def procesar_pura(datos, umbral):
    return [x * 2 for x in datos if x > umbral]

# Si necesitas el log, devuélvelo también
def procesar_con_log(datos, umbral):
    procesados = [x for x in datos if x > umbral]
    log = [f"procesado: {x}" for x in procesados]
    resultado = [x * 2 for x in procesados]
    return resultado, log

resultado, log = procesar_con_log([50, 150, 80, 200], 100)
print(resultado)
print(log)

La versión pura devuelve el log como valor en lugar de escribirlo en una variable global. Quien llama a la función decide qué hacer con el log.

datos_brutos = [10, None, -5, 20, 30, None, 15]

resultado = pipeline(
    datos_brutos,
    quitar_nulos,
    quitar_negativos,
    normalizar,
    redondear
)
print(resultado)   # [0.33, 0.67, 1.0, 0.5]

Es más legible porque el orden de las transformaciones es explícito y se lee de arriba a abajo — igual que un pipeline de análisis de datos real. Añadir o quitar un paso es trivial.

La IA genera código funcional porque es más predecible — las funciones puras son fáciles de verificar y de combinar. También porque el código funcional es más general — una función de orden superior funciona con cualquier dato que tenga la forma correcta.

En análisis de datos el paradigma funcional encaja perfectamente porque los datos no se modifican — se transforman en copias nuevas. Pandas está diseñado así: df.dropna(), df.groupby(), df.merge() devuelven DataFrames nuevos sin tocar el original.

El paradigma imperativo sigue siendo mejor cuando el rendimiento es crítico — los bucles explícitos a veces son más rápidos — o cuando la lógica es inherentemente secuencial y con mucho estado compartido.

Las cinco señales: filter — función de orden superior, map — función de orden superior, lambda — función anónima como argumento, sorted con criterio — orden superior, sin variables de estado — sin bucles ni acumuladores.

No es legible — demasiado anidamiento en una sola expresión. La reescritura más clara:

def es_valido(x):
    return x is not None and x > 0

datos_limpios = list(filter(es_valido, datos))
maximo = max(datos_limpios)
normalizado = [round(x / maximo, 2) for x in datos_limpios]
resultado = sorted(normalizado, reverse=True)
print(resultado)

resultado = (
    df
    .dropna(subset=["ventas"])
    .query("region == 'Norte'")
    .assign(categoria=lambda d:
            d["ventas"].apply(
                lambda v: "alto" if v > 100 else "bajo"
            ))
    .sort_values("ventas", ascending=False)
    .reset_index(drop=True)
)

Ambos producen el mismo resultado. El enfoque A es imperativo — variable de estado, bucle explícito, acumulación. El enfoque B es funcional — una expresión, sin estado, declarativo.

Para este caso simple ambos son igual de legibles. Cuando la lógica crece — más condiciones, más transformaciones — el enfoque funcional escala mejor porque cada parte es independiente y verificable. El enfoque imperativo puede ser preferible cuando hay que depurar paso a paso o cuando el rendimiento es crítico.

def quitar_vacios(datos):
    return [x for x in datos if x.strip()]

def a_mayusculas(datos):
    return [x.upper() for x in datos]

def sin_duplicados(datos):
    return list(dict.fromkeys(datos))

def ordenar(datos):
    return sorted(datos)

procesar_strings = componer_muchas(
    ordenar,
    sin_duplicados,
    a_mayusculas,
    quitar_vacios
)

strings = ["python", "", "datos", "PYTHON",
           "  ", "análisis", "datos"]
print(procesar_strings(strings))
# ['ANÁLISIS', 'DATOS', 'PYTHON']