Una función lambda es una función anónima de una sola expresión que puedes escribir en el lugar exacto donde la necesitas, sin pararla a definir con def en otro lado. La sintaxis es lambda parámetros: expresión, y el resultado de esa expresión es el valor de retorno implícito.
La palabra clave aquí es anónima. Lambda existe para los casos en que la función es tan pequeña y tan puntual que darle nombre y apartado propio sería más ruido que señal. No es una versión compacta de def para uso general, sino una herramienta de conveniencia con restricciones deliberadas.
¿Por qué esas restricciones? Porque Python las impone por diseño. Una lambda solo acepta una expresión: nada de if/else como statements, nada de for, nada de return explícito, nada de anotaciones de tipo. Si pudieras meter todo eso en una lambda, ya tendrías un def sin nombre y el resultado sería ilegible. La limitación te fuerza a usarla solo donde realmente no necesitas más.
El momento adecuado es cuando pasas una función simple como argumento a sorted(), map(), filter(), o cualquier función de orden superior, y esa función no va a vivir en ningún otro lugar. Si aparece una vez, inline, y su lógica cabe en una expresión corta, lambda añade claridad porque mantiene el contexto junto.
El error clásico es hacer exactamente lo contrario: asignarle la lambda a una variable, f = lambda x: x * 2. En ese momento la función ya tiene nombre, y PEP 8 lo dice con todas las letras: usa def. Una función definida con def puede tener docstring, anotaciones de tipo, es más fácil de depurar (aparece con su nombre en trazas de error en lugar de <lambda>), y es igual de concisa para casos simples.
from functools import reduce
# --- Uso correcto: argumentos inline en funciones de orden superior ---
products = [
{"name": "teclado", "price": 75.0},
{"name": "monitor", "price": 320.0},
{"name": "ratón", "price": 40.0},
{"name": "auriculares", "price": 110.0},
]
# Lambda inline: el criterio de ordenación vive justo donde se usa
sorted_by_price = sorted(products, key=lambda p: p["price"])
# filter devuelve un iterador; lambda describe el criterio directamente
affordable = list(filter(lambda p: p["price"] < 100, products))
# map transforma cada elemento; la transformación es obvia en una línea
prices = list(map(lambda p: p["price"], products))
# reduce con lambda para un cálculo puntual
total = reduce(lambda acc, price: acc + price, prices, 0.0)
print("Ordenados por precio:", [p["name"] for p in sorted_by_price])
print("Asequibles:", [p["name"] for p in affordable])
print("Total:", total)
# --- Antipatrón: lambda con nombre → usa def ---
# ❌ Esto no aporta nada sobre def y pierde sus ventajas
apply_tax = lambda price: price * 1.21 # noqa: E731 (el linter te avisa)
# ✅ Mismo resultado, pero con docstring, anotaciones y nombre en el traceback
def apply_tax(price: float) -> float:
"""Aplica el IVA estándar del 21 % a un precio base."""
return price * 1.21
prices_with_tax = list(map(apply_tax, prices))
print("Con IVA:", [round(p, 2) for p in prices_with_tax])
Qué está pasando en cada decisión
El sorted() con key=lambda p: p["price"] es el caso de uso más natural de lambda. La función de clave existe únicamente para esa llamada; no tiene sentido nombrarla get_price_from_product_dict y definirla treinta líneas arriba. El lector ve el criterio de ordenación justo donde ocurre la ordenación.
Lo mismo pasa con filter() y map(). La lambda describe en el sitio qué se filtra y cómo se transforma. No es necesario saltar a otra parte del archivo para entender la intención.
El reduce() merece un comentario aparte: aquí la lambda actiene dos parámetros (acc y price) y expresa una acumulación. Funciona bien porque la lógica es trivial. Si la acumulación fuera compleja, la lambda empezaría a oscurecer en lugar de aclarar, y sería señal de extraerla a un def.
El bloque del antipatrón muestra por qué f = lambda ... es problemático. Cuando ejecutas ese código y hay un error dentro, el traceback dice in <lambda> en lugar de in apply_tax. Además, no puedes añadir docstring ni anotaciones de tipo a una lambda. El linter (flake8, ruff) incluso levanta la advertencia E731 específicamente para este patrón, lo que indica que hay consenso en la comunidad de que es mal estilo.
La versión def apply_tax(price: float) -> float tiene exactamente el mismo comportamiento, pero es introspeccionable, documentable, tipable, y aparece con nombre útil en cualquier herramienta de depuración.
Errores que debes conocer
Error: intentar meter lógica condicional compleja en una lambda porque “cabe”.
# ❌ Wrong
classify = lambda x: "alto" if x > 100 else "medio" if x > 50 else "bajo"
# ✅ Right
def classify(x: float) -> str:
if x > 100:
return "alto"
if x > 50:
return "medio"
return "bajo"
La expresión ternaria anidada es técnicamente válida en Python, pero hay que leerla dos veces para entender el orden de las condiciones. Cuando el cerebro tiene que esforzarse, el código está fallando en su trabajo principal.
Error: usar lambda cuando necesitas que la función sea reutilizable o testeable.
# ❌ Wrong — no puedes referenciar esta función en un test de forma directa
result = sorted(data, key=lambda x: x.score * x.weight)
# ✅ Right
def ranking_key(x):
return x.score * x.weight
result = sorted(data, key=ranking_key)
# En el test: assert ranking_key(item) == expected_value
Al extraer la lógica a ranking_key puedes escribir un test unitario sobre esa función de forma aislada, algo imposible con una lambda anónima dentro de otra llamada.
N° 113