Zipline Backtesting Engine

Hola, soy Alex de DEV STORIES DOT EU. Zipline Backtesting Engine, episodio 1 de 7. La mayoría de los algoritmos de trading parecen brillantes sobre el papel, pero pierden dinero al instante en los mercados reales. El sospechoso habitual es el look-ahead bias. Tu código, por error, mira el precio de cierre de mañana para hacer el trade de hoy. El Event-Driven Backtesting Engine de Zipline 3.0 evita esto por completo. En un backtester vectorizado estándar, cargas un dataframe enorme de precios históricos y aplicas operaciones de pandas a toda la timeline a la vez. Esto es rápido, pero tiene fallos enormes a la hora de simular la realidad. Puedes escribir fácilmente lógica que dispare una orden de compra hoy basándose en una rolling average que, por error, incluya datos de la semana que viene. Zipline te quita esa posibilidad obligándote a usar un stream event-driven estricto. Simula un exchange financiero real. Cuando ejecutas un backtest, el engine actúa como un cronómetro estricto. Avanza por el historial, tick a tick, o minuto a minuto. En cada paso, dispara un evento. Tu código solo recibe los datos disponibles en ese microsegundo exacto. Inspeccionas el estado actual, metes tus órdenes, y luego esperas a que el engine avance el reloj. No puedes mirar hacia adelante, porque los datos futuros aún no se han transmitido por stream al engine. Esta arquitectura garantiza que tu backtest refleje las limitaciones reales del live trading. Sin embargo, procesar una timeline financiera evento a evento en Python puro crea un cuello de botella enorme. Podrías estar procesando años de datos de precios a nivel de minuto de miles de acciones individuales. Para que este event loop sea computacionalmente viable, Zipline delega muchísimo trabajo a las C-extensions. El core engine se apoya en rutinas precompiladas para procesar los números lo bastante rápido como para ser útil. Esta dependencia de las C-extensions introduce un punto de fricción importante. Montar un environment cuantitativo robusto desde cero es notoriamente difícil. Zipline no es una herramienta standalone de Python. Requiere una integración profunda con librerías científicas a nivel de sistema. Por ejemplo, usa TA-Lib, una librería estándar para generar indicadores técnicos de mercado. También depende de paquetes que necesitan LAPACK y BLAS para cálculos pesados de álgebra lineal. Son codebases de C y Fortran complejos y legacy. Si intentas montar este environment usando un simple comando pip install, casi seguro que te chocarás contra un muro de errores de compilación. Pip se descarga el código fuente de estas dependencias e intenta compilarlas en local. Esto requiere que tu sistema operativo tenga un compilador de C, un compilador de Fortran correctamente configurados, y los header files del sistema correctos ya instalados. La mayoría de los sistemas operativos base no traen esto out of the box. Por eso la documentación de Zipline recomienda explícitamente usar conda en lugar de pip. Conda no es solo un package manager de Python. Es un gestor de binarios a nivel de sistema y de environment. Cuando creas un environment de conda e instalas Zipline a través del canal conda-forge, no estás compilando nada desde el código fuente. Conda descarga binarios precompilados para tu sistema operativo específico. Gestiona las C-extensions, TA-Lib y LAPACK sin problemas. El dependency tree se resuelve por ti, dándote un environment estable y listo para el desarrollo algorítmico. Aquí está la clave. El event loop estricto que hace que Zipline sea matemáticamente honesto es exactamente lo que le obliga a depender de dependencias de C pesadas y compiladas para ejecutarse a escala. Al entender esta arquitectura, entiendes por qué la instalación es compleja, y por qué conda es la única forma sensata de montar tu environment. Si quieres ayudar a que el programa siga adelante, puedes apoyarnos buscando DevStoriesEU en Patreon. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Zipline Backtesting Engine, episodio 2 de 7. Configuras un contador simple en tu lógica de trading usando una variable global de Python, y a mitad del backtest, se reinicia o lanza un error. En el backtesting event-driven, las variables globales estándar son una trampa. Para sobrevivir a miles de eventos de mercado simulados, necesitas una forma segura de trackear el estado, que es exactamente donde el Algorithm Lifecycle y el State Management de Zipline entran en juego. Cada algoritmo de Zipline requiere al menos dos funciones fundamentales: initialize y handle data. Zipline es un sistema event-driven. Recorre los datos históricos cronológicamente, disparando un evento para cada intervalo de tiempo. La función initialize se ejecuta exactamente una vez cuando empieza tu backtest. Recibe un único argumento llamado context. Piensa en context como la memoria persistente de tu algoritmo. Por debajo es un simple diccionario de Python, pero actúa como un namespace dedicado. En lugar de declarar variables globales estándar, guardas tu estado directamente en context. Si quieres hacer seguimiento de un activo específico, como las acciones de Apple, lo buscas en initialize y lo asignas a context punto asset. Esto asegura que la referencia sobreviva desde el primer día del backtest hasta el último. La siguiente es la función handle data. Esta se llama cada vez que hay un nuevo evento de mercado, como una nueva barra de trading diaria. Recibe dos argumentos: context y data. Ya conoces context. Ahí es donde lees el estado que configuraste antes o actualizas las variables en ejecución. El segundo argumento, data, representa el entorno actual del mercado. Es tu lente hacia la simulación en ese momento exacto. Usas data para comprobar si un activo es tradable en ese momento, para obtener su precio actual, o para pedir una ventana histórica de precios. Imagina una estrategia estándar de cruce de medias móviles duales. En tu función initialize, defines tu activo objetivo y lo asocias a context. Dentro de handle data, le pides al objeto data los precios de los últimos treinta días para calcular una media móvil corta, y de los últimos trescientos días para una media móvil larga. Comparas las dos medias. Si la media móvil corta cruza por encima de la media móvil larga, es una señal de compra. Ejecutas esto llamando a la función order, pasándole tu context punto asset y un número objetivo de acciones. El trading es solo la mitad del trabajo. También necesitas trackear cómo rinden tus indicadores a lo largo del tiempo. Zipline proporciona una función built-in llamada record. Al final de tu bloque handle data, llamas a record y le pasas tu media móvil corta, tu media móvil larga y el precio actual. Zipline recopila estos valores registrados en cada paso y los adjunta al dataframe de rendimiento final que se devuelve al terminar el backtest. Cuando tu código esté listo, tienes dos formas de ejecutarlo. La primera es a través de la interfaz de línea de comandos. Le pasas tu script de Python al comando run de Zipline, especificando tus fechas de inicio y fin, tu capital inicial y un archivo de salida para los resultados de rendimiento. Esto es ideal para pipelines automatizados o ejecución remota. El segundo método es interactivo. Si utilizas Jupyter Notebooks, puedes usar el magic command built-in de Zipline. Escribiendo porcentaje porcentaje zipline en la parte superior de una celda del notebook, defines y ejecutas el algoritmo inline, pasándole tus fechas y capital como argumentos al magic command. Los resultados se inyectan directamente en un dataframe local, listos para su análisis inmediato. Aquí está la clave. Zipline te obliga a dividir tu algoritmo en dos objetos distintos: context para el estado interno que controlas, y data para el entorno del mercado externo. Respeta ese límite, y tu State Management se mantendrá perfectamente sincronizado a lo largo de miles de trades. Eso es todo por este episodio. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Zipline Backtesting Engine, episodio 3 de 7. Tu lógica de trading puede ser impecable, pero si cargas archivos CSV enormes en memoria cada vez que ejecutas una simulación, tu velocidad de iteración se quedará estancada. El cuello de botella rara vez es tu algoritmo. Es tu data pipeline. Zipline resuelve este problema utilizando Market Data Bundles y Custom Ingestion. Un data bundle es una colección de precios de activos y metadatos que ha sido precompilada en un formato de almacenamiento altamente optimizado. En lugar de parsear archivos de texto raw durante un run, Zipline lee de un almacenamiento binario comprimido y de una base de datos local rápida. Esta separación del procesamiento de datos de la ejecución de la estrategia hace que los backtests sean excepcionalmente rápidos. Puedes lanzar esta compilación desde la línea de comandos con el comando zipline ingest, seguido del nombre del bundle. Zipline incluye un bundle por defecto llamado Quandl, que descarga datos históricos diarios estándar de equities desde internet y los escribe directamente en tu disco local. La mayoría de los entornos profesionales dependen de datos propietarios. Para usar tus propios datos, debes crear un custom bundle. Crear un custom bundle requiere escribir una ingest function. Esta función actúa como un traductor dedicado entre tu fuente de datos raw y el formato de almacenamiento interno de Zipline. Aquí está la clave. La ingest function no devuelve un dataset personalizado. En su lugar, Zipline pasa varios objetos writer a tu función, y tu código inyecta los datos raw en esos writers. La signature de la ingest function requiere parámetros específicos para gestionar este routing. Recibe una configuración de entorno, el trading calendar, las sesiones de inicio y fin, y los objetos writer. Los dos objetos críticos con los que interactuarás son el asset database writer y el daily bar writer. El asset database writer gestiona tus metadatos. Le pasas una tabla estructurada que contiene tus símbolos, sus fechas de inicio y fin, y los nombres de sus exchanges. El writer compila esto en una base de datos local para que el engine sepa exactamente qué activos existen en cualquier trading session. El daily bar writer procesa la acción del precio real. Le proporcionas un iterador que devuelve bloques de datos de precios. Cada bloque contiene un identificador interno de activo emparejado con una tabla de sus datos de open, high, low, close y volume. El writer coge estos bloques y los comprime en el disco. Zipline ofrece un mecanismo integrado para gestionar flat files estándar utilizando el CSV directory bundle, comúnmente llamado csvdir. Configuras tus datos propietarios guardando archivos CSV individuales en una sola carpeta, nombrando cada archivo con su ticker. Luego, registras este directorio en un script de configuración específico de Zipline llamado extension file. El registro simplemente vincula el nombre de tu custom bundle con la ingest function subyacente para que la herramienta de línea de comandos sepa que existe. Cuando ejecutas zipline ingest con tu nuevo nombre personalizado, el sistema apunta la ingest function hacia tu carpeta. Itera sobre los archivos CSV, extrae los metadatos, alimenta al asset database writer y bombea las filas de precios históricos hacia el daily bar writer. El parseo de texto, que es lento y costoso, ocurre exactamente una vez. Tras la ingesta, tus datos propietarios se almacenan permanentemente en el formato optimizado, accesibles al instante para miles de iteraciones de backtest a alta velocidad. El verdadero poder de la custom ingestion es que desacopla estrictamente la preparación de datos de la ejecución de tu estrategia, asegurando que la lógica de parseo lento nunca contamine tu testing environment. Eso es todo por este episodio. ¡Nos vemos en la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Zipline Backtesting Engine, episodio 4 de 7. Los splits de activos y los dividendos pueden invalidar instantáneamente tu historial de precios. Si una acción sufre un split de dos por uno, un loop de backtesting simple interpretará que el precio se ha desplomado un 50 %. Esto lo evitas utilizando la Algorithm API y las interacciones con BarData, que gestionan automáticamente los ajustes point-in-time. En Zipline, la lógica central de tu algoritmo interactúa con un objeto, generalmente llamado data, que es una instancia de BarData. Este objeto se pasa a tus event handlers, como tu main data handler o tus scheduled functions. Su función principal es proporcionar datos de precios y volumen exactamente como aparecieron en ese momento específico de la simulación, evitando por completo el look-ahead bias. Cuando llamas a data punto current, le pasas un activo y un campo, como precio o volumen. Te proporciona el valor más reciente disponible en ese minuto o día exacto de la simulación. Cuando necesitas una lookback window para calcular una moving average o la volatilidad histórica, llamas a data punto history. Le proporcionas el activo, el campo, el número de bars y la frecuencia, como un día o un minuto. Aquí está la clave. Tanto current como history ajustan automáticamente la información devuelta para las corporate actions, pero solo hasta el momento de la simulación actual. Tus moving averages no se desviarán drásticamente en la fecha ex-dividendo porque los precios históricos se ajustan para alinearse perfectamente con el marco de precios actual. Obtienes una time series matemáticamente continua sin tener que gestionar manualmente los multiplicadores de las corporate actions. Antes de actuar en función de esos datos de precios, debes verificar si el activo es realmente negociable en ese preciso momento. Pasarle tu activo a data punto can trade comprueba si el exchange está abierto para ese activo y si está cotizando activamente. Si una acción fue delisted ayer, o aún no ha realizado su IPO, esto devuelve false. A continuación, tienes data punto is stale. Si un activo tiene muy poca liquidez y no se negoció durante la bar actual, Zipline hará un forward-fill del último precio conocido para evitar errores de missing data. Sin embargo, si ejecutas una estrategia de mean-reversion con precios que tienen forward-fill, estás operando con datos fantasma. data punto is stale devuelve true si el precio que ves proviene de un período anterior en lugar de una operación reciente. Verificar tanto el tradability como el staleness antes de realizar una orden evita una gran cantidad de errores de simulación. Esto cubre los inputs; pasemos ahora al execution timing. Por defecto, Zipline llama a tu main data handler en cada bar de simulación. Si ejecutas una estrategia a nivel de minuto, ejecutar una lógica de rebalance compleja cada sesenta segundos ralentizará considerablemente tu backtest y generará costes de transacción poco realistas. La solución es el método schedule function. Lo usas dentro de la fase de initialization de tu algoritmo para registrar una función personalizada específica que se ejecutará en un horario preciso. Requiere tres argumentos principales: primero, la función que quieres ejecutar; segundo, una date rule; y tercero, una time rule. Supongamos que quieres ejecutar un rebalance de portfolio exactamente treinta minutos antes del cierre del mercado. Pasas tu función de rebalance como primer argumento. Para la date rule, usas el helper method date rules punto every day. Para la time rule, usas time rules punto market close, pasando treinta minutos como argumento de offset. Ahora, en lugar de ejecutarse cientos de veces al día, tu lógica de rebalance se ejecuta exactamente una vez, justo cuando finaliza la sesión de negociación. La separación entre el objeto BarData para un acceso seguro a los datos y la scheduling API para el execution timing garantiza que la lógica principal de tu algoritmo solo se ejecute cuando corresponda, utilizando los precios que existían realmente en ese preciso momento. Me gustaría aprovechar este momento para agradecerte que nos escuches; nos ayuda mucho. ¡Que tengas un buen día!

Hola, soy Alex de DEV STORIES DOT EU. Zipline Backtesting Engine, episodio 5 de 7. Tu algoritmo detecta una señal de salida perfecta y lanza una orden de venta masiva. El problema es que es sábado. Si tu backtesting engine no sabe que el exchange está cerrado, esa orden o se ejecuta en un mercado fantasma o crashea toda tu simulación. Los Custom Trading Calendars mapean la realidad de los horarios de los mercados globales para evitar exactamente este escenario. Un trading calendar en Zipline es la source of truth absoluta para las sesiones de mercado. Dicta cuándo se pueden ingestar datos y cuándo se pueden procesar las órdenes. Por defecto, Zipline asume un horario estándar de acciones de Estados Unidos. Si quieres hacer trading con acciones internacionales, futuros o activos alternativos, tienes que definir las reglas específicas de esos exchanges. Esto lo haces creando una clase custom que hereda de la clase base Trading Calendar de Zipline. Solo necesitas configurar unas pocas properties específicas para establecer los límites del trading day. Primero, configuras el open time. Esto dicta la hora y el minuto exactos en los que el mercado empieza a aceptar órdenes. Segundo, configuras el close time, marcando el último minuto de la trading session. Tercero, defines los regular holidays. Esta es una colección de fechas específicas en las que el exchange está completamente cerrado, como los festivos nacionales. Zipline no hace todo este cálculo de fechas desde cero. Utiliza muchísimo la librería pandas, específicamente las clases Holiday Calendar y Custom Business Day de pandas. Cuando pasas tu lista de regular holidays, básicamente estás poblando un objeto Holiday Calendar de pandas. Zipline combina esta lógica de pandas con tus open y close times definidos para generar un index masivo y precalculado de cada minuto de trading válido para toda la duración de tu backtest. Este cálculo previo es crucial. Significa que tu algoritmo no está evaluando matemáticas de fechas complejas durante cada tick de la simulación. Simplemente hace una query a un array altamente optimizado. Esta es la parte que importa. No todos los mercados duermen. Si estás simulando trades de criptomonedas, las suposiciones estándar sobre los fines de semana arruinarán el alineamiento de tus datos. Tienes que construir un calendar continuo veinticuatro siete. Vamos a ver cómo construir uno, al que llamaremos TFS Exchange Calendar. Defines tu nueva clase y heredas de la clase base estándar. Para el open time, especificas la medianoche. Para el close time, especificas las once y cincuenta y nueve PM, dándote un ciclo diario completo. Como los exchanges de criptomonedas no observan los festivos tradicionales, configuras la property regular holidays para que devuelva una lista vacía. El último paso es ajustar el horario semanal. Los trading calendars tradicionales usan un objeto Custom Business Day de pandas configurado estrictamente de lunes a viernes. Para tu TFS calendar, sobrescribes esta property weekmask para incluir explícitamente el sábado y el domingo. Una vez que la clase está completa, la registras en el entorno de Zipline usando un identificador string custom. A partir de ese momento, tanto tus bundles de ingesta de datos como tus algoritmos de trading reconocerán el horario continuo. Las órdenes se procesarán secuencialmente sin saltarse los fines de semana, y los datos a nivel de minuto se mapearán perfectamente con los timestamps del mundo real. Si las reglas de tu calendar están mal configuradas, tus datos de precios se desalinearán y tus métricas de rendimiento serán completamente ficticias. Los límites de tiempo dictan cada acción en un event-driven engine, y los trading calendars son exactamente la forma en la que haces cumplir esos límites. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Zipline Backtesting Engine, episodio 6 de 7. Calcular métricas de riesgo complejas en cada tick puede ralentizar tu backtest hasta casi detenerlo. Quieres que tus simulaciones sean rápidas, pero también necesitas saber exactamente cómo se comporta tu estrategia bajo estrés. De hecho, puedes desactivar el tracking por defecto durante el debugging, o escribir trackers personalizados muy optimizados. Este episodio trata sobre Risk Performance Metrics y Custom Evaluation. Zipline agrupa sus cálculos de riesgo y performance integrados en una estructura llamada Metric Set. El set por defecto genera automáticamente estadísticas estándar como el beta, el Sharpe ratio y los retornos totales. Cuando tu simulación termina, Zipline empaqueta todos estos cálculos en el DataFrame de performance. Cada métrica trackeada se convierte en una columna, y cada fila representa un time step en tu simulación. Si no necesitas todas estas métricas por defecto, puedes pasar un Metric Set reducido al iniciar el engine, ahorrando un tiempo de procesamiento significativo. Cuando las métricas por defecto no capturan tu modelo de riesgo específico, defines una custom metric. Esto lo haces creando una subclass del objeto metric base de Zipline. Escribir una custom metric significa hacer un hook directamente al reloj interno de la simulación. Tú controlas exactamente cuándo se ejecuta tu lógica implementando tres métodos de lifecycle específicos: start of simulation, end of session y end of bar. Start of simulation es donde inicializas las variables y configuras el estado inicial. End of session se ejecuta una vez al cierre del día de trading. End of bar se ejecuta después de cada actualización de precio, lo cual es crítico para las estrategias a nivel de minuto. Cada vez que se dispara uno de estos hooks basados en tiempo, Zipline le pasa dos argumentos obligatorios: el ledger y el packet. El ledger guarda el estado matemático en vivo de tu simulación. Contiene el valor actual de tu portfolio, los balances de efectivo y todas las posiciones abiertas. Debes tratar el ledger como datos de solo lectura. El packet, por otro lado, es un dictionary vacío que representa el payload de datos para ese time step específico. Tú escribes en el packet. Cualquier key-value pair que asignes al dictionary del packet se convierte instantáneamente en una columna de tu DataFrame de performance final. Vamos a ver cómo trackear el maximum intraday drawdown usando el hook de end of bar. Primero, defines tu clase de custom metric. En el método start of simulation, creas dos variables: una para trackear el valor más alto del portfolio visto hasta ahora, y otra para el maximum drawdown actual. Ambas empiezan en cero. Aquí está la clave. Como las caídas intradiarias son invisibles si solo compruebas los precios de cierre diarios, debes ejecutar tu lógica dentro del método end of bar. Dentro de este método, lees el valor actual del portfolio desde el argumento ledger. Si el valor actual es mayor que tu valor más alto registrado, actualizas el high water mark. Si es menor, calculas la caída porcentual. Si esa caída supera tu maximum drawdown registrado, actualizas la variable de maximum drawdown. Finalmente, coges tu variable de maximum drawdown y la asignas a una key en el argumento packet. Al escribir en el packet al final de cada bar, tu DataFrame de performance final contendrá un registro granular, minuto a minuto, de la peor caída intradiaria experimentada. Las custom metrics son, fundamentalmente, solo observers que leen el ledger de la simulación y escriben en el packet de salida, dándote control total sobre qué se mide y cuándo. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue desarrollando!

Hola, soy Alex de DEV STORIES DOT EU. Zipline Backtesting Engine, episodio 7 de 7. Pasas meses perfeccionando un algoritmo en un simulador, pero el mercado real no acepta órdenes de trading simuladas. Zipline se diseñó principalmente para backtesting, pero su arquitectura modular significa que puedes omitir por completo la simulación interna y enrutar directamente a un motor de ejecución real. Extender la arquitectura de Zipline hace posible esta transición. Por defecto, Zipline funciona como un sistema cerrado. Le pasas datos históricos de precios, calcula señales y empareja internamente tus órdenes con el comportamiento pasado del mercado. El sistema aísla intencionadamente tu algoritmo de las redes externas. Pero un sistema de trading moderno tarde o temprano necesita comunicarse con el mundo exterior. Necesitas una forma de intercambiar los componentes de simulación internos por módulos personalizados que gestionen datos en vivo y capital real. Zipline gestiona este requisito mediante un mecanismo de extensión basado en un archivo de inicialización específico llamado extension punto py. Este archivo actúa como un registro local para tu entorno. Cuando arranca el framework Zipline, busca inmediatamente aquí los overrides definidos por el usuario. Usas este archivo para registrar nuevos bundles de datos, modelos de comisiones personalizados y motores de ejecución alternativos. El componente más crítico que debes intercambiar para el trading en vivo es el Blotter. El Blotter actúa como el sistema interno de gestión de órdenes. Rastrea las órdenes abiertas, las cancela cuando se le indica y procesa los fills de las operaciones. El blotter de simulación por defecto finge ejecutar operaciones basándose en algoritmos históricos de volumen y slippage. Para hacer trading en vivo, debes omitir esto por completo. Esto lo consigues escribiendo una clase Blotter personalizada. En lugar de simular la ejecución, los métodos de tu clase hacen llamadas de red a la API de un bróker real. Cuando el algoritmo solicita una operación, tu blotter personalizado formatea esa solicitud en una orden en vivo y la transmite al exchange. Aquí está la clave. No modificas ni una sola línea del código fuente original de Zipline para implementar esto. Defines tu clase blotter personalizada en tu propio espacio de trabajo. Luego, abres extension punto py. Importas la función de registro del blotter desde el módulo de utilidades de Zipline. Le pasas a esta función un string único con el nombre de tu bróker, junto con tu clase blotter personalizada. Eso registra tu motor de ejecución a nivel global. Finalmente, cuando ejecutas tu script de trading desde la línea de comandos o un notebook, simplemente proporcionas el string con el nombre de tu blotter personalizado como parámetro de lanzamiento. El framework intercambia la maquinaria interna automáticamente. Exactamente el mismo algoritmo que se ejecutó en simulación ahora está haciendo trading con capital real. Soportar este nivel de modularidad requiere una base central altamente estable. Zipline depende en gran medida de dataframes numéricos rápidos y almacenamiento en bases de datos relacionales para mover información entre el algoritmo y el blotter. Con el lanzamiento de Zipline 3.0, la arquitectura central recibió una importante actualización estructural para modernizar esta base. Toda la plataforma se migró para soportar Pandas 2.0 y SQLAlchemy 2.0. Actualizar a Pandas 2.0 aporta una gestión de memoria sustancialmente mejor y tiempos de ejecución más rápidos para los enormes arrays de series temporales que Zipline procesa en cada tick. SQLAlchemy 2.0 moderniza por completo la forma en que el motor interactúa con las bases de datos SQL subyacentes. Impone rutas de ejecución de queries más estrictas y explícitas cuando el sistema gestiona los metadatos de los activos y almacena los resultados del trading. Estas mejoras fundamentales garantizan que, tanto si estás ejecutando un backtest histórico masivo como si estás enrutando órdenes en vivo a través de una extensión de bróker personalizada, el motor opera sobre el estándar moderno de la infraestructura de datos de Python. Al separar la lógica de trading de la mecánica de ejecución, la arquitectura garantiza que tu algoritmo permanezca completamente intacto mientras la capa de ejecución subyacente se adapta a la realidad. Te animo encarecidamente a que explores la documentación oficial y pruebes a escribir tus propias extensiones de forma práctica. Si tienes ideas sobre lo que deberíamos tratar a continuación, visita DEV STORIES DOT EU para sugerir temas para nuestras futuras series. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.