CPython da marcha atrás: Rust será opcional y no un requisito del intérprete

Los mantenedores de CPython han aparcado la idea de convertir Rust en una dependencia obligatoria del intérprete de referencia. Lo que sigue adelante es un plan más modesto: una API de Rust opcional para el desarrollo interno de Python, pensada para la versión 3.16, prevista para octubre de 2027. Tomáš Šedovič, responsable del programa de Rust, explicó en RustConf —celebrada en Montreal la semana pasada— que el nuevo enfoque "esquiva muchas de las preocupaciones que planteó la gente".

De obligatorio a opcional

La propuesta original la presentó en noviembre la programadora de Python Emma Smith. Buscaba meter soporte de Rust en Python, en principio para escribir módulos de extensión, con la intención de fondo de que Rust acabara siendo requisito en todo el código de CPython, igual que hoy lo es C. La memoria de C se gestiona a mano, con los fallos de seguridad que eso arrastra; Rust los elimina en tiempo de compilación. El atractivo era evidente.

El problema es que no todas las implementaciones de Python corren sobre plataformas que soporten Rust, y compilar Rust requiere a su vez Python, lo que crea una dependencia circular en el proceso de build. A eso se suma la resistencia habitual a cualquier actualización forzada. En mayo, Smith modificó el texto para quitarle el carácter obligatorio y dejarlo para una propuesta futura. La idea pasó a ser permitir módulos de extensión opcionales: quien quiera usar Rust, que lo use; quien no, que no lo toque.

Guido van Rossum, creador del lenguaje, respaldó ese camino en la discusión: "Todos sabemos que una reescritura completa en Rust no va a funcionar, pero empezar introduciendo Rust en componentes menos esenciales y dejar que poco a poco vaya tomando los más esenciales suena a un buen plan".

Lo que queda por resolver

El trabajo técnico sigue. Rust necesita soporte de GCC, algo imprescindible para la larga cola de plataformas poco comunes que CPython mantiene. Los dos lenguajes construyen de forma distinta sus bibliotecas estándar y sus bibliotecas compartidas dinámicas, y eso hay que reconciliarlo. Python necesitará además algún tipo de saneador entre lenguajes que evite estados de memoria inseguros, y ahí ya hay esfuerzos en marcha, como BorrowSanitizer. El reto más complicado, según Šedovič, es ampliar el trait Drop de Rust para que los objetos de Python reciban contexto en tiempo de ejecución al liberarse de memoria.

Python también mira hacia Rust en el terreno de las herramientas. La propuesta original elogiaba Cargo como sistema de build, y con razón: descarga dependencias, las compila, las enlaza y las prueba. En el ecosistema Python eso son hoy varias herramientas separadas. uv, un gestor de paquetes y proyectos escrito en Rust, va justo en esa dirección.

Con la 3.16 como horizonte, la API incluirá la biblioteca de compresión zlib de Rust como crate de prueba. Van Rossum bromeó con que, a este paso, CPython tendrá que llamarse CRPython.