Conceptos Avanzados en Python

1. La versión LBYL lee la cantidad con if texto.isdigit(): return int(texto) y devuelve None en otro caso. La versión EAFP hace try: return int(texto) except ValueError: return None. ¿Con qué entrada dan resultados distintos?

• "-1": LBYL devuelve None y EAFP devuelve -1
• "dos": LBYL lanza ValueError y EAFP devuelve None
• "3": LBYL devuelve 3 y EAFP devuelve "3"
• "" (texto vacío): LBYL devuelve 0 y EAFP devuelve None

"-1".isdigit() es False, así que LBYL devuelve None, mientras que int("-1") da -1. Las comprobaciones previas suelen quedarse cortas; EAFP deja que int decida.

2. FilaInvalidaError hereda de ValueError y guarda num_linea y motivo. Pedido.desde_fila la lanza con raise FilaInvalidaError(...) from None cuando int("dos") falla. ¿Qué afirmación es correcta?

• Un except ValueError la atrapa, y el traceback no muestra el ValueError original de int()
• Un except LookupError la atrapa, porque el dato no se encontró en el catálogo
• from None la convierte en un ValueError genérico y se pierden num_linea y motivo
• El traceback muestra ambos errores unidos por «The above exception was the direct cause»

Un except ValueError atrapa también sus subclases. from None deja __cause__ en None y suprime el contexto: el traceback muestra solo el error propio, con sus atributos intactos.

3. Se configura logging.basicConfig(level=logging.INFO) y luego log.debug("a"), log.info("b") y log.warning("c"). ¿Qué mensajes se emiten?

• Solo b y c: DEBUG está por debajo de INFO
• Los tres: basicConfig solo cambia el formato
• Solo c: INFO deja pasar únicamente advertencias
• Solo a: el nivel indica el máximo que se muestra

Los niveles son DEBUG 10, INFO 20, WARNING 30, ERROR 40 y CRITICAL 50; con nivel INFO se descarta todo lo menor a 20. Salen «b» y «c».

4. Se lanza ExceptionGroup("lote con errores", [tres FilaInvalidaError, KeyError("ciudad")]) y el try tiene dos cláusulas: except* FilaInvalidaError y except* KeyError. ¿Qué ocurre?

• Se ejecutan las dos cláusulas: una recibe las 3 filas y la otra el KeyError
• Solo se ejecuta la primera cláusula que coincide, como con except
• Se ejecuta la primera y el KeyError se pierde sin aviso
• Lanza SyntaxError: no se pueden combinar dos except* en un mismo try

except* reparte el grupo por tipo y, a diferencia de except, pueden ejecutarse varias cláusulas. La primera recibe las 3 filas (líneas 111, 138 y 141) y la segunda el KeyError.

5. Alguien reescribe cronometro con @contextmanager sin try/finally: t0 = time.perf_counter(); yield; registro[etiqueta] = time.perf_counter() - t0. ¿Qué pasa si el bloque with lanza FilaInvalidaError?

• La excepción sale del with y el tiempo no se registra
• El tiempo se registra y la excepción queda silenciada
• El context manager reintenta el bloque una vez antes de propagar el error
• Python lanza RuntimeError porque un generador de contexto exige finally

La excepción reaparece en el yield, así que la línea siguiente no se ejecuta y el registro queda vacío. Con try/finally el tiempo se guarda siempre y la excepción sigue su camino.