⏱️ Lectura: 9 min
Si alguna vez abriste un intérprete de Python y escribiste import this, viste aparecer un texto críptico y poético. Ese texto es el Zen de Python: 19 aforismos escritos por Tim Peters en junio de 1999 que condensan la filosofía de diseño del lenguaje.🔄 Actualizado el 16 de abril de 2026
📑 En este artículo
- Cómo ver el Zen de Python
- Los 19 principios explicados
- 1. Hermoso es mejor que feo
- 2. Explícito es mejor que implícito
- 3. Simple es mejor que complejo
- 4. Complejo es mejor que complicado
- 5. Plano es mejor que anidado
- 6. Disperso es mejor que denso
- 7. La legibilidad cuenta
- 8. Los casos especiales no son suficientes para romper las reglas
- 9. Aunque lo práctico le gana a la pureza
- 10. Los errores nunca deben pasar en silencio
- 11. A menos que se silencien explícitamente
- 12. Frente a la ambigüedad, rechaza la tentación de adivinar
- 13. Debería haber una — y preferiblemente solo una — manera obvia de hacerlo
- 14. Aunque esa manera puede no ser obvia al principio, a menos que seas holandés
- 15. Ahora es mejor que nunca
- 16. Aunque nunca es frecuentemente mejor que ahora mismo
- 17. Si la implementación es difícil de explicar, es una mala idea
- 18. Si la implementación es fácil de explicar, puede ser una buena idea
- 19. Los espacios de nombres son una gran idea — ¡hagamos más!
- El principio número 20
- Cómo aplicar el Zen en tu código diario
- Preguntas frecuentes
- Referencias
No son reglas rígidas. Son principios de diseño que guían decisiones cuando escribes código Python — y que aplican a cualquier lenguaje. Están documentados oficialmente como PEP 20.
Cómo ver el Zen de Python
Abre cualquier intérprete de Python y ejecuta:
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
...El módulo this viene incluido en la biblioteca estándar desde Python 2.2. No necesitas instalar nada.
💡 Dato curioso: El código fuente de this.py está intencionalmente ofuscado con un cifrado ROT13 — una broma interna que contradice los propios principios del Zen.
Los 19 principios explicados
1. Hermoso es mejor que feo
“Beautiful is better than ugly.”
Python valora el código legible y estéticamente limpio. No se trata de arte, sino de claridad visual.
# Feo ❌
x=[(i**2) for i in range(10) if i%2==0 and i>2]
# Hermoso ✅
numeros_pares = [
numero ** 2
for numero in range(10)
if numero % 2 == 0 and numero > 2
]2. Explícito es mejor que implícito
“Explicit is better than implicit.”
Que el código diga exactamente lo que hace. Sin magia oculta ni efectos secundarios sorpresivos.
# Implícito ❌ — ¿qué hace process?
from utils import *
result = process(data)
# Explícito ✅ — queda claro de dónde viene
from utils import clean_whitespace
result = clean_whitespace(user_input)3. Simple es mejor que complejo
“Simple is better than complex.”
Si puedes resolver algo con una función simple, no construyas una clase con herencia.
# Complejo ❌
class StringReverser:
def __init__(self, text):
self.text = text
def reverse(self):
return self.text[::-1]
resultado = StringReverser("python").reverse()
# Simple ✅
def invertir(texto):
return texto[::-1]
resultado = invertir("python")4. Complejo es mejor que complicado
“Complex is better than complicated.”
A veces la complejidad es necesaria. Pero complejo (muchas partes bien organizadas) no es lo mismo que complicado (difícil de entender). Un ORM como SQLAlchemy es complejo pero no complicado.
5. Plano es mejor que anidado
“Flat is better than nested.”
Evita la pirámide de la muerte. Usa retornos tempranos.
# Anidado ❌
def procesar_pedido(pedido):
if pedido:
if pedido.es_valido():
if pedido.tiene_stock():
if pedido.pago_confirmado():
return enviar(pedido)
return None
# Plano ✅
def procesar_pedido(pedido):
if not pedido:
return None
if not pedido.es_valido():
return None
if not pedido.tiene_stock():
return None
if not pedido.pago_confirmado():
return None
return enviar(pedido)6. Disperso es mejor que denso
“Sparse is better than dense.”
No metas toda la lógica en una sola línea. Dale espacio al código para respirar.
# Denso ❌
return {k: v for k, v in sorted(data.items(), key=lambda x: x[1], reverse=True) if v > threshold}
# Disperso ✅
filtrados = {k: v for k, v in data.items() if v > threshold}
ordenados = dict(sorted(filtrados.items(), key=lambda x: x[1], reverse=True))
return ordenados7. La legibilidad cuenta
“Readability counts.”
Quizás el principio más importante. El código se lee muchas más veces de las que se escribe. Nombres descriptivos, estructura clara, sin abreviaciones crípticas.
# Ilegible ❌
def f(l, n):
return [x for x in l if x > n]
# Legible ✅
def filtrar_mayores(numeros, umbral):
return [n for n in numeros if n > umbral]8. Los casos especiales no son suficientes para romper las reglas
“Special cases aren’t special enough to break the rules.”
Mantén la consistencia. Si tu API retorna diccionarios, no retornes una tupla en un caso edge “porque es más fácil”.
9. Aunque lo práctico le gana a la pureza
“Although practicality beats purity.”
El contrapeso del principio anterior. A veces romper una convención está justificado si la alternativa pura es absurdamente compleja. Python mismo hace esto: len() es una función global, no un método, por razones prácticas.
10. Los errores nunca deben pasar en silencio
“Errors should never pass silently.”
No uses except: pass. Si algo falla, que se note.
# Silencioso ❌ — ¿qué falló? Nunca lo sabrás
try:
resultado = conectar_api()
except:
pass
# Explícito ✅
try:
resultado = conectar_api()
except ConnectionError as e:
logger.error(f"Fallo de conexión a la API: {e}")
raise11. A menos que se silencien explícitamente
“Unless explicitly silenced.”
Si decides ignorar un error, hazlo de forma consciente y documentada:
try:
cache.delete(key)
except CacheError:
pass # Intencional: el caché es best-effort, no crítico12. Frente a la ambigüedad, rechaza la tentación de adivinar
“In the face of ambiguity, refuse the temptation to guess.”
Por esto Python no convierte "1" + 1 automáticamente como lo haría JavaScript. Si es ambiguo, que falle con un TypeError claro.
13. Debería haber una — y preferiblemente solo una — manera obvia de hacerlo
“There should be one — and preferably only one — obvious way to do it.”
El anti-Perl. En Python hay una forma idiomática de hacer las cosas. Por ejemplo, para iterar una lista:
# No idiomático ❌
for i in range(len(nombres)):
print(nombres[i])
# Pythónico ✅
for nombre in nombres:
print(nombre)14. Aunque esa manera puede no ser obvia al principio, a menos que seas holandés
“Although that way may not be obvious at first unless you’re Dutch.”
Una referencia a Guido van Rossum, creador de Python y holandés. El humor sutil de Tim Peters.
15. Ahora es mejor que nunca
“Now is better than never.”
No esperes a tener la solución perfecta para empezar. Escribe código, itera, mejora.
16. Aunque nunca es frecuentemente mejor que ahora mismo
“Although never is often better than right now.”
El contrapeso: no te apresures a implementar algo sin pensarlo. Es mejor no agregar una feature que agregarla mal y tener que mantenerla para siempre.
💡 Tip: Los principios 15 y 16 juntos dicen: actúa, pero piensa antes de actuar. Aplica especialmente a APIs públicas — una vez publicadas, no puedes quitarlas.
17. Si la implementación es difícil de explicar, es una mala idea
“If the implementation is hard to explain, it’s a bad idea.”
Si no puedes explicar tu código a un compañero en 2 minutos, probablemente necesita un rediseño.
18. Si la implementación es fácil de explicar, puede ser una buena idea
“If the implementation is easy to explain, it may be a good idea.”
Nota el “puede ser”. Que sea simple de explicar no garantiza que sea correcto — pero es buena señal.
19. Los espacios de nombres son una gran idea — ¡hagamos más!
“Namespaces are one honking great idea — let’s do more of those!”
Los módulos, paquetes, clases y funciones de Python son todos espacios de nombres. Evitan colisiones y mantienen el código organizado:
# Sin namespaces ❌ — ¿de qué librería viene 'connect'?
from db import *
from cache import *
connect() # ¿cuál connect?
# Con namespaces ✅
import db
import cache
db.connect()
cache.connect()El principio número 20
Tim Peters dejó el aforismo 20 vacío intencionalmente — reservado para Guido van Rossum. Después de más de 25 años, sigue sin escribirse. Algunos dicen que el silencio es el mensaje: no todo necesita ser dicho.
Cómo aplicar el Zen en tu código diario
No necesitas memorizar los 19 principios. Cuando estés escribiendo código y dudes entre dos enfoques, pregúntate:
- ¿Es legible? — Alguien que no escribió este código, ¿lo entendería?
- ¿Es explícito? — ¿Queda claro lo que hace sin leer la implementación interna?
- ¿Es simple? — ¿Puedo resolver esto con menos abstracción?
- ¿Los errores son visibles? — Si algo falla, ¿me voy a enterar?
📝 Nota: El Zen de Python aplica más allá de Python. Estos principios son universales para escribir código limpio en cualquier lenguaje — desde JavaScript hasta Rust.
Preguntas frecuentes
¿Quién escribió el Zen de Python?
Tim Peters, un contribuidor histórico de CPython conocido por el algoritmo de ordenamiento Timsort (usado en Python, Java y Android). Escribió los 19 aforismos en junio de 1999 y los publicó en la lista de correo comp.lang.python.
¿El Zen de Python es obligatorio?
No. Son guías de diseño, no reglas estrictas. El propio Zen dice “lo práctico le gana a la pureza”. Son principios para cuando dudas entre dos formas de resolver algo.
¿Por qué son 19 y no 20?
Tim Peters dejó el aforismo 20 reservado para Guido van Rossum, creador de Python. Nunca lo escribió. Es parte de la tradición y el humor de la comunidad Python.
Referencias
- PEP 20 — The Zen of Python (python.org)
- Código fuente de this.py (CPython en GitHub)
- Documentación del módulo this (docs.python.org)
Síguenos en t.me/programacion para más contenido tech diario.
0 Comentarios