Por Canuto  

CPython dejó en pausa la idea de volver obligatorio a Rust y ahora prepara una API opcional para incorporar sus ventajas sin romper plataformas ni procesos de compilación.
***

  • CPython ya no plantea que Rust sea una dependencia obligatoria para toda su implementación de referencia.
  • La API de Rust está prevista para Python 3.16, con zlib como componente de prueba.
  • La integración todavía debe resolver compatibilidad con GCC, bibliotecas, sanitizadores y el manejo de memoria.

El proyecto CPython modificó su estrategia para incorporar Rust y dejó en pausa la posibilidad de convertirlo en una dependencia obligatoria de la implementación de referencia de Python. En su lugar, los desarrolladores trabajan en una API opcional que permitirá construir módulos y componentes internos con Rust, una fórmula gradual que busca conservar los beneficios de la seguridad de memoria sin imponer una migración completa a todos los usuarios y plataformas.

La decisión representa un cambio relevante frente a la propuesta planteada en noviembre pasado por la programadora de Python Emma Smith, quien había sugerido comenzar con módulos de extensión y, a largo plazo, hacer que Rust pudiera utilizarse en toda la base de código de CPython. Según explicó Tomáš Šedovič, gerente de programación de Rust, el nuevo enfoque evita muchas de las preocupaciones que surgieron durante el debate, especialmente entre quienes temían una transición forzada y compleja.

Una integración menos invasiva

Rust atrae a los responsables de CPython por una razón técnica central: su modelo de seguridad de memoria detecta determinados errores durante la compilación, en lugar de dejar que aparezcan cuando el programa ya está funcionando. Python, como gran parte de su implementación actual, depende ampliamente de C, un lenguaje en el que los desarrolladores deben asignar y liberar memoria manualmente, una tarea que puede abrir la puerta a fallos difíciles de detectar y potencialmente relevantes para la seguridad.

La propuesta original pretendía que Rust asumiera una relación con CPython parecida a la que hoy mantiene C con el proyecto, pero ese objetivo generó resistencia dentro de la comunidad. No todas las implementaciones de Python se ejecutan en plataformas con soporte adecuado para Rust, por lo que una dependencia obligatoria podía excluir sistemas que forman parte de la llamada cola larga de entornos compatibles con CPython.

También apareció un problema de construcción: compilar Rust requiere Python, lo que puede crear una dependencia cíclica durante el proceso de compilación de la propia herramienta. A esa dificultad se sumó la resistencia habitual de las comunidades de software libre ante actualizaciones impuestas, sobre todo cuando afectan el lenguaje, las herramientas y las plataformas necesarias para mantener un proyecto de amplia distribución.

En mayo, Smith modificó su propuesta para retirar el mandato de que Rust fuera obligatorio y dejó esa discusión para una iniciativa futura. La alternativa consiste en que los desarrolladores de CPython puedan crear módulos de extensión opcionales con Rust, aunque también conserven la libertad de no utilizarlo cuando las restricciones técnicas, operativas o de compatibilidad hagan más conveniente continuar con otras herramientas.

El respaldo a un avance gradual

Guido van Rossum, creador de Python, respaldó la estrategia más prudente y reconoció que una reescritura completa de CPython en Rust no sería viable. Su planteamiento es introducir primero el lenguaje en componentes menos esenciales y permitir que, con el tiempo, pueda asumir responsabilidades más importantes si la experiencia demuestra que la integración es segura, estable y útil para los mantenedores.

La lógica de ese plan se parece a una prueba controlada dentro de un sistema crítico: Rust puede demostrar sus ventajas en áreas acotadas sin obligar a toda la comunidad a modificar sus compiladores, sus paquetes o sus procesos de distribución al mismo tiempo. Para CPython, esa gradualidad también permite medir el impacto sobre el rendimiento, la portabilidad y el mantenimiento antes de tomar decisiones de mayor alcance.

El trabajo actual incluye la incorporación de Rust al proceso de compilación y el diseño de una interfaz que permita utilizar crates, nombre que reciben las bibliotecas del ecosistema de Rust, para construir partes de Python. La API está prevista para Python 3.16, cuya publicación se espera para octubre de 2027, y la versión incluiría la biblioteca de compresión zlib escrita en Rust como componente de prueba.

Šedovič y otros integrantes del proyecto Rust han conversado con los desarrolladores principales de CPython para ajustar el lenguaje a las necesidades específicas de Python. El objetivo no es simplemente insertar código nuevo, sino crear una convivencia sostenible entre dos ecosistemas con reglas distintas para compilar, enlazar bibliotecas y administrar los objetos durante todo su ciclo de vida.

Los obstáculos técnicos que siguen abiertos

Uno de los requisitos más importantes es que Rust mantenga soporte para GCC, la colección de compiladores de GNU utilizada por la larga lista de plataformas menos comunes que CPython todavía respalda. Si esa compatibilidad no queda resuelta, una integración aparentemente beneficiosa podría reducir la portabilidad del lenguaje y dejar fuera precisamente a los sistemas que dependen de una implementación amplia y flexible.

Rust y Python también difieren en la forma de construir sus bibliotecas estándar y sus bibliotecas dinámicas compartidas individuales. Esas diferencias deben conciliarse para que los componentes puedan compilarse, enlazarse y distribuirse sin introducir conflictos en las herramientas que utilizan los desarrolladores, los distribuidores de sistemas operativos y quienes mantienen implementaciones especializadas.

Otro frente corresponde a los sanitizadores entre lenguajes, necesarios para detectar estados inseguros de memoria que puedan aparecer cuando C y Rust manejan asignaciones de manera diferente. Ya existen esfuerzos como BorrowSanitizer, impulsados por problemas similares en las integraciones entre C, C++ y Rust, pero CPython necesitará comprobar que esas herramientas funcionen de forma confiable dentro de su propio modelo de objetos y de ejecución.

El reto más complejo podría estar relacionado con el trait Drop de Rust, que determina qué ocurre cuando un objeto deja de utilizarse y se libera de la memoria. Para integrarlo con Python, ese mecanismo tendría que ampliarse de modo que los objetos puedan recibir contexto del entorno de ejecución al ser destruidos, una tarea que, según Šedovič, exigirá un esfuerzo intelectual considerable por parte de los ingenieros de Rust.

Lo que Python puede adoptar de Rust

La influencia no necesariamente viajará en una sola dirección, porque los responsables de Python también observan herramientas del ecosistema de Rust que podrían simplificar el desarrollo. La propuesta de noviembre describía Cargo como un sistema de construcción especialmente sólido, ya que reúne en un mismo flujo tareas que en el universo Python suelen depender de herramientas separadas.

Cargo descarga dependencias, las compila, las enlaza con otras bibliotecas y ejecuta pruebas, además de acompañar distintas etapas del ciclo de vida de un proyecto. En Python, esas funciones suelen repartirse entre herramientas de inicialización de proyectos, construcción, pruebas y publicación, una fragmentación que puede aumentar la complejidad para quienes mantienen aplicaciones y bibliotecas durante largos periodos.

Python ya está siguiendo parte de ese modelo con uv, un gestor unificado de paquetes y proyectos escrito en Rust. La herramienta busca concentrar tareas que antes exigían soluciones separadas, lo que muestra que la colaboración entre ambos lenguajes no depende únicamente de reescribir componentes internos de CPython, sino también de incorporar ideas de desarrollo que hagan más eficiente el trabajo cotidiano.

La adopción de Rust, por tanto, avanza como una asimilación progresiva y no como una sustitución inmediata de C o una transformación total del núcleo de Python. Van Rossum incluso bromeó con la posibilidad de renombrar CPython como “CRPython”, pero el calendario previsto y los problemas técnicos indican que el proyecto todavía tendrá que demostrar, paso a paso, que sus ventajas justifican la complejidad adicional.

Una decisión con impacto en el ecosistema

La decisión de mantener Rust como una opción reduce la presión sobre los mantenedores que trabajan con plataformas antiguas, arquitecturas poco comunes o cadenas de compilación específicas. También permite que los equipos adopten el lenguaje donde su seguridad de memoria aporte una ventaja clara, sin convertir la disponibilidad de un compilador o una herramienta concreta en una condición para ejecutar CPython.

Ese equilibrio puede resultar especialmente importante para una implementación que sirve de base a numerosos proyectos, distribuciones y entornos de desarrollo. Una migración obligatoria habría ofrecido una dirección tecnológica más uniforme, pero también habría trasladado los costos de compatibilidad, aprendizaje y mantenimiento a una comunidad que no necesariamente comparte las mismas prioridades ni dispone de las mismas herramientas.

La estrategia revisada tampoco cierra la puerta a una presencia mayor de Rust en el futuro. Si la API funciona, los componentes de prueba superan las dificultades de integración y las herramientas de diagnóstico reducen los riesgos, el proyecto podría ampliar progresivamente el uso del lenguaje en áreas más sensibles sin tener que comenzar con una imposición general.

Por ahora, el calendario apunta a Python 3.16 y a la utilización de zlib como una primera demostración concreta, mientras continúan las conversaciones sobre GCC, bibliotecas compartidas, sanitización y destrucción de objetos. El resultado definirá si Rust se convierte en una pieza cada vez más importante de CPython o si sus costos de integración mantienen su papel como una herramienta opcional para componentes específicos.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados