Los generadores de Python se implementan como objetos de marco suspendidos (PyFrameObject) que mantienen su estado de ejecución entre invocaciones. Cuando se llama a send(value), la función interna gen_send_ex() de CPython empuja este valor en la pila de valores del generador, que luego la expresión yield saca y devuelve al llamador. Esto difiere de la llamada inicial next(), que envía implícitamente None para preparar el generador desde su estado inicial (donde f_lasti == -1) hasta la primera expresión yield. Si se llama a send() con un valor que no es None antes de que el generador haya producido la primera vez, CPython genera un TypeError porque el marco del generador carece de una posición en la pila para recibir el valor. Esta distinción arquitectónica asegura que la comunicación bidireccional solo comience después de que el generador haya alcanzado su primer punto de suspensión.
Necesitábamos implementar un canal de datos consciente de la presión de retroceso para procesar flujos de datos de mercado de alta frecuencia, donde los consumidores aguas abajo podrían señalar dinámicamente a los productores aguas arriba para limitar o reanudar el flujo de datos sin perder mensajes ni agotar la memoria.
Un enfoque considerado utilizó threading con instancias limitadas de queue.Queue entre las etapas del canal. Aunque esto proporcionó semánticas de bloqueo familiares y seguridad de subprocesos, sufrió de una contención severa del GIL y una sobrecarga de cambio de contexto, consumiendo un 15% de CPU solo para la coordinación a altas tasas de procesamiento, mientras que agregaba picos de latencia impredecibles.
Otra alternativa implicaba migrar a corutinas asyncio y la sintaxis async/await. Esto habría eliminado la contención del GIL, pero requería una reescritura completa de nuestra biblioteca de análisis numérico síncrona en una forma compatible con async, creando una refactorización viral que tocaría miles de líneas de lógica empresarial e introduciría problemas de compatibilidad con las extensiones heredadas de C.
Finalmente, seleccionamos un enfoque de multitarea cooperativa basado en generadores utilizando send() para transmitir "créditos de demanda" aguas arriba. Esta solución evitó la sobrecarga del GIL por completo, no requirió reescrituras de bibliotecas, ya que los generadores funcionan en código síncrono, y proporcionó un flujo de control explícito a través de patrones demand = (yield data_chunk) que permitieron a los consumidores aguas abajo pausar la producción aguas arriba de inmediato al enviar valores cero.
El resultado fue una reducción del 40% en el uso de memoria en comparación con el enfoque de cola, la latencia se estabilizó por debajo de 5 milisegundos, y la base del código permaneció legible con puntos de yield explícitos marcando los límites de suspensión.
¿Por qué, al llamar a send() con un valor distinto de None en un generador recién creado, se genera un TypeError, y cómo hace esta restricción cumplir el protocolo de generador?
Cuando se crea un generador por primera vez, su puntero de marco f_lasti es -1, lo que indica que no se ha ejecutado ningún bytecode. El intérprete de CPython verifica si el generador no ha sido iniciado cuando se invoca send(); si el valor enviado no es None, genera un TypeError porque la expresión yield aún no se ha alcanzado para proporcionar un espacio en la pila para el valor. Esta obligación asegura que la lógica de inicialización del generador se complete antes de que comience la comunicación bidireccional, manteniendo la invariante de que los valores fluyan hacia el generador solo en puntos de suspensión explícitos yield.
¿Cómo asegura generator.close() que el código de limpieza dentro del generador se ejecute, y qué distingue la excepción GeneratorExit de las excepciones regulares?
El método close() envía una excepción GeneratorExit al generador en su punto de suspensión actual al llamar a throw(GeneratorExit). GeneratorExit hereda de BaseException en lugar de Exception para evitar que sea capturada por controladores except Exception genéricos que podrían absorberla inapropiadamente. Si el generador captura GeneratorExit y la vuelve a lanzar o sale normalmente, close() regresa en silencio; sin embargo, si el generador produce un valor en respuesta a GeneratorExit, CPython genera un RuntimeError porque un generador que se cierra no debe producir nuevos valores. Este mecanismo garantiza que los bloques finally y los administradores de contexto dentro del cuerpo del generador se ejecuten incluso durante una terminación forzada.
¿Qué mecanismo permite a yield from manejar valores enviados de manera transparente a través de generadores anidados, y cómo se diferencia esto de la delegación manual usando un bucle con send()?
La sintaxis yield from delega no solo la iteración, sino el protocolo completo del generador a un subgenerador. Cuando el generador externo ejecuta yield from subgen(), CPython transforma el send(value) del llamador en un envío directo al subgenerador hasta que se genera StopIteration (cuyo valor se convierte en el resultado de la expresión yield from). Esto difiere de la delegación manual en la que un bucle como for x in subgen(): yield x no puede interceptar los valores enviados al generador externo para reenviarlos al interno. La construcción yield from esencialmente aplana la pila de llamadas, permitiendo el flujo de datos bidireccional a través de la anidación arbitrariamente profunda de generadores sin código de reenvío repetitivo, manteniendo al mismo tiempo una correcta propagación de excepciones y semánticas de cierre.