Esta es la lección de saldar la deuda más antigua del curso. Desde el módulo 6 escribes with ruta.open() as f: aceptando dos promesas: "el archivo se cierra solo, pase lo que pase" y "algún día veremos cómo funciona por dentro". El módulo 7 añadió la pista clave — el try/finally garantiza la limpieza incluso con excepciones — y la lección anterior te enseñó un with dentro de un generador. Hoy se cierra el círculo: el protocolo __enter__/__exit__ que hay detrás de cada with, y con él construiremos administradores de contexto propios para Papyrus, incluida una TransaccionCatalogo que deja el catálogo a salvo si una venta se rompe a medias.

1. Qué hace realmente el with
2. El protocolo: __enter__ y __exit__
3. Reimplementar (conceptualmente) el with de archivos
4. Un administrador propio como clase: TransaccionCatalogo
5. __exit__ y las excepciones: propagar o suprimir
6. contextlib.@contextmanager: la versión generador
7. Otros usos: cronometrar un bloque, cambiar de directorio
8. Clase vs @contextmanager: tabla de decisión

Empecemos por lo que el with no es: no es un bloque mágico "para archivos". Es azúcar sintáctico sobre un patrón try/finally que ya sabrías escribir a mano con lo aprendido en 07-02:

Cualquier objeto que implemente esos dos métodos dunder — y ya sabes de dunders por el módulo 5 — puede usarse con with. Se le llama administrador de contexto (context manager): administra la entrada y la salida de un contexto, garantizando la salida.

Los tres argumentos de __exit__ describen qué pasó dentro del bloque:

• Si el bloque terminó bien: los tres son None.
• Si el bloque lanzó: exc_type es la clase de la excepción (p. ej. StockInsuficienteError), exc_val la instancia (con sus atributos titulo, solicitado, disponible de 07-04) y exc_tb el traceback.

Es decir: __exit__ es un finally con superpoderes — no solo se ejecuta siempre, sino que además sabe si hubo excepción y cuál.

Para fijar el concepto, escribamos nuestro propio "open" conceptual (el de verdad está en C, pero el protocolo es idéntico):

Si dentro del bloque algo lanza, verás [exit] cerrando ... (excepción: <class '...'>) antes de que la traza llegue a tu pantalla: la limpieza ocurrió, y la excepción siguió su camino hacia las anillas de 07-04. Exactamente las dos promesas del with, ahora sin misterio.

Ahora un administrador que resuelve un problema de verdad. vender() descuenta stock y luego se registra la venta y se guarda el catálogo. ¿Qué pasa si Ana vende un lote de tres títulos a Marta y el segundo lanza StockInsuficienteError? El primero ya se descontó: el catálogo queda a medias, en un estado que no corresponde a ninguna venta real. Queremos semántica de transacción: o todo, o nada.

deepcopy (primo profundo del copy que rozamos en M4) fotografía catálogo y libros; restaurar mutando con clear()/update() — en vez de reasignar — mantiene válida cualquier otra referencia al mismo diccionario. Su uso en el mostrador:

Secuencia: se venden 2 Hamlet (stock 6 → 4)... y La Odisea con 9 unidades pedidas y 4 disponibles lanza StockInsuficienteError. __exit__ la ve llegar, restaura la foto — Hamlet vuelve a 6 — deja constancia a WARNING en papyrus.log, y devuelve False: la excepción sigue subiendo hasta el except ErrorPapyrus del mostrador, que informa con la calma de 07-04. Nadie perdió datos; nadie silenció nada.

El valor devuelto por __exit__ es un interruptor delicado:

• False (o None, que es lo que devuelve un método sin return): la excepción se propaga. Es lo correcto en el 95 % de los casos — el administrador limpia, no decide.
• True: la excepción se suprime, como si el bloque hubiera ido bien. Solo tiene sentido cuando suprimir es el servicio que ofreces (p. ej. contextlib.suppress(FileNotFoundError), que la biblioteca estándar ya trae hecho).

Un return True descuidado es el except: pass de 07-04 disfrazado de elegancia. Si dudas, False.

Escribir una clase entera para "haz algo antes, haz algo después" puede ser mucha ceremonia. contextlib ofrece un atajo que reúne las dos lecciones anteriores — un decorador aplicado a un generador:

La correspondencia exacta:

• Todo lo anterior al yield es el __enter__.
• El valor del yield es lo que recibe el as.
• El generador queda pausado en el yield (tal cual lo viste en 08-03) mientras se ejecuta el cuerpo del with.
• Si el bloque lanza, la excepción aparece en el punto del yield — por eso se envuelve en try/except (o try/finally si solo hay que limpiar).
• Reanudar y terminar sin más equivale a propagar normalidad; raise propaga la excepción; atraparla sin relanzar equivale al return True.

El mismo comportamiento que la clase, en un tercio de líneas.

Cualquier patrón "preparar / deshacer" encaja. Dos ejemplos útiles en Papyrus:

Fíjate en que cronometro hace con un bloque lo que @cronometrar hacía con una función: decoradores y context managers son las dos caras de "envolver código".

Regla práctica: empieza con @contextmanager; pásate a la clase cuando necesites estado, configuración o una jerarquía.

• Olvidar el try alrededor del yield en un @contextmanager: si el bloque lanza, tu código de limpieza no se ejecuta — el generador muere en el yield. El try/finally (o try/except + raise) no es opcional: es el equivalente del __exit__.
• return True (o atrapar sin relanzar) por accidente: suprime excepciones que el mostrador esperaba. Síntoma típico: "la venta falló pero no saltó ningún error". Revisa el retorno de __exit__ antes que nada.
• Hacer trabajo pesado en __init__ en vez de __enter__: TransaccionCatalogo(catalogo) sin with no debería fotografiar nada todavía. __init__ guarda parámetros; __enter__ adquiere.
• Copiar superficialmente cuando hay objetos anidados: dict(catalogo) copia el diccionario pero no los Libro; la reversión dejaría stocks corruptos. Para transacciones, copy.deepcopy.
• Consejo: si escribes try/finally alrededor de un recurso más de una vez, es la señal de que ahí vive un context manager con nombre propio.
• Consejo: se pueden encadenar en un solo with: with transaccion_catalogo(cat) as c, cronometro("venta"): — se salen en orden inverso al que se entró.

1. Escribe como clase el administrador RegistroBloque(nombre) que al entrar escriba en el log INICIO <nombre> y al salir FIN <nombre> (ok) o FIN <nombre> (error: <ExcTipo>) según haya habido excepción, propagándola siempre. Pruébalo envolviendo una venta que lance StockInsuficienteError.
2. Reescribe RegistroBloque con @contextmanager (llámalo registro_bloque). ¿Qué construcción sustituye a la comprobación if exc_type is not None?
3. Escribe copia_de_seguridad(ruta) con @contextmanager: antes del bloque copia el archivo a copias/<nombre>.bak (usa shutil.copy2, de M6); si el bloque falla, restaura el .bak sobre el original y relanza; si va bien, no hace nada más. Úsalo alrededor de guardar_catalogo.

1. class RegistroBloque:
       def __init__(self, nombre: str):
           self.nombre = nombre
   
       def __enter__(self):
           logger.info("INICIO %s", self.nombre)
           return self
   
       def __exit__(self, exc_type, exc_val, exc_tb):
           if exc_type is None:
               logger.info("FIN %s (ok)", self.nombre)
           else:
               logger.error("FIN %s (error: %s)", self.nombre, exc_type.__name__)
           return False    # propagar siempre
   
   with RegistroBloque("venta lote Marta"):
       vender(catalogo, "La Odisea", 9)    # lanza StockInsuficienteError
   

   En papyrus.log queda INICIO + FIN ... (error: StockInsuficienteError), y la excepción sigue hacia el mostrador.

2. @contextmanager
   def registro_bloque(nombre: str):
       logger.info("INICIO %s", nombre)
       try:
           yield
           logger.info("FIN %s (ok)", nombre)
       except Exception as e:
           logger.error("FIN %s (error: %s)", nombre, type(e).__name__)
           raise
   

   La comprobación if exc_type is not None se convierte en la estructura try/except: el camino sin excepción sigue tras el yield; el camino con excepción entra por el except — y el raise final preserva la propagación.

3. import shutil
   from contextlib import contextmanager
   
   @contextmanager
   def copia_de_seguridad(ruta: Path):
       respaldo = BASE / "copias" / (ruta.name + ".bak")
       shutil.copy2(ruta, respaldo)
       try:
           yield ruta
       except Exception:
           shutil.copy2(respaldo, ruta)   # restaurar el original
           raise
   
   with copia_de_seguridad(BASE / "datos" / "catalogo.json") as ruta:
       guardar_catalogo(catalogo, ruta)
   

   Es la TransaccionCatalogo llevada al disco: la misma idea (foto → intentar → restaurar si falla → relanzar) aplicada a un archivo en vez de a un diccionario.

Promesa saldada: el with era un protocolo de dos dunders — __enter__ prepara, __exit__ limpia siempre y decide con su retorno si la excepción se propaga (casi siempre False) — montado sobre el mismo try/finally de 07-02. Papyrus ganó TransaccionCatalogo, que garantiza ventas de todo-o-nada, y las versiones @contextmanager demostraron que decoradores (08-02) y generadores (08-03) no eran temas sueltos: aquí trabajan juntos. Con esto, el código de Papyrus es expresivo y eficiente... pero sigue haciendo una cosa cada vez: si consultar el precio de un libro a una distribuidora tarda dos segundos, consultar a tres tarda seis, con el programa parado esperando. Las dos últimas lecciones del módulo atacan esa espera: primero con hilos y procesos — y una conversación honesta sobre el famoso GIL — y después con asyncio.