CPython esquiva la polémica por Rust y opta por una transición voluntaria

CPython decidió probar Rust no por mandato, sino como experimento. El equipo Rust for CPython eligió un camino que permita integrar el nuevo lenguaje en el proyecto sin reconstruir por completo toda la cadena de compilación. Los componentes de la biblioteca estándar proponen escribirse en Rust, pero permanecer opcionales, de modo que la falta del nuevo compilador no impida compilar el intérprete en plataformas habituales y raras.

La idea inicial era más estricta. En noviembre de 2025 los autores del pre-PEP admitían que Rust con el tiempo podría convertirse en una dependencia obligatoria de CPython y emplearse en todo el código. Tras la discusión la propuesta se redujo rápidamente a módulos de extensión opcionales, y la obligatoriedad de Rust se pospuso para un posible PEP futuro que la comunidad deberá debatir por separado.

Ese enfoque resuelve de entrada varios puntos polémicos. CPython funciona no solo en las masivas plataformas x86-64 y ARM, y Rust no está disponible por igual en todas partes. Además, la propia compilación de Rust utiliza Python, por lo que una dependencia obligatoria crearía un ciclo: para un nuevo Python se necesitaría Rust, y para compilar Rust ya haría falta Python.

La motivación técnica, sin embargo, no desaparece. Una parte importante de CPython está escrita en C, donde los errores de gestión de memoria pueden causar desbordamientos de búfer, accesos a objetos ya liberados y condiciones de carrera. Rust evita muchas de esas fallas en tiempo de compilación, aunque las secciones unsafe y la frontera entre Rust y C seguirán exigiendo control adicional.

La adopción gradual ya se ha convertido en estrategia común de grandes proyectos de sistema. En Linux el soporte de Rust avanzó desde la experimentación hasta convertirse en herramienta estable, y en abril de 2026 el lenguaje dejó de considerarse experimental para el núcleo. CPython, no obstante, no replica directamente el modelo del kernel y por ahora no exige a los mantenedores manejar dos lenguajes simultáneamente.

El proyecto Rust for CPython ya ha creado una rama separada del intérprete con soporte para Cargo y experimenta con una API interna en Rust. La primera tarea de esa interfaz no es una biblioteca pública para terceros, sino una vinculación segura del código nuevo con las estructuras internas de CPython. La estabilización pública de la API se planea discutir más adelante en una propuesta aparte.

Uno de los proyectos de prueba fue zlib-py, un módulo pequeño que conecta la implementación zlib-rs con Python. Las pruebas del propio proyecto muestran una aceleración notable en varias operaciones de compresión y descompresión, aunque escenarios concretos, incluido CRC32 en ARM64, pueden funcionar más despacio. Ese prototipo sirve, ante todo, para verificar la compilación, las interfaces y el comportamiento de Rust junto a C.

El trabajo está pensado para Python 3.16. En el plan de abril el equipo orientó el primer código en Rust precisamente a esa rama, cuyo lanzamiento final se espera el 5 de octubre de 2027. Antes de eso el proyecto deberá resolver cuestiones de enlazado, verificación compartida de memoria en C y Rust y la liberación correcta de objetos de Python considerando el estado del intérprete en distintos entornos.

Una dificultad aparte está en las herramientas de compilación. Cargo gestiona cómodamente dependencias y compilación, pero CPython durante décadas ha construido un proceso portátil en torno a compiladores C y a sus propios scripts. Los equipos de Rust y Python discuten el soporte de GCC, la compatibilidad de bibliotecas y formas de no obligar a las distribuciones a cambiar sus cadenas habituales solo por un componente opcional.

Como resultado, por ahora no se trata de reescribir Python en Rust. Incluso Guido van Rossum apoyó el enfoque gradual, en el que el nuevo lenguaje aparece primero en partes menos críticas. Para Rust esa vía ya demostró su viabilidad en otras grandes bases de código, donde la seguridad de la memoria se convirtió en el principal argumento a favor de migraciones puntuales en lugar de reemplazos totales del código antiguo.

La principal conclusión de la estrategia actual es separar el experimento técnico del requisito obligatorio. Los desarrolladores de CPython obtienen la oportunidad de probar Rust en código real, y los empaquetadores de distribuciones y los responsables de plataformas inusuales no deben cambiar su entorno por adelantado. La cuestión de convertir a Rust en una parte obligatoria de CPython queda abierta y requerirá una decisión aparte tras las pruebas.