El Python Language Summit 2026 debate Rust y un nuevo GC

La Python Software Foundation publicó el 30 de septiembre sus informes del Python Language Summit 2026. El summit es donde los desarrolladores del núcleo de Python discuten el futuro del lenguaje antes de que algo se convierta en una propuesta formal. Uno de los planes más concretos vino del equipo Rust for CPython: llevar Rust a CPython, el intérprete principal de Python, paso a paso.

El resumen de la PSF cuenta que 47 desarrolladores del núcleo e invitados se reunieron el 14 de julio de 2026 en Cracovia, Polonia, durante EuroPython 2026. Escucharon 10 charlas completas y 5 charlas relámpago. Fue el primer summit en Europa desde Florencia en 2011. "A partir de ahora, el Python Language Summit se alternará cada año entre PyCon US y EuroPython", escribe la PSF. Seth Larson escribió los informes, y LWN los señaló a sus lectores ese mismo día.

Rust pasa de experimento a plan

David Hewitt habló en nombre del equipo Rust for CPython, que dirigen Kirill Podoprigora y Emma Smith y que tiene unos 60 desarrolladores. El equipo quiere añadir Rust a CPython poco a poco, empezando por módulos pequeños y autónomos.

El primer candidato es zlib, el módulo de compresión, construido sobre la biblioteca zlib-rs. El informe de Python Insider cita al equipo, que considera zlib-rs "más rápido que zlib y zlib-ng en muchas plataformas". El argumento a favor de Rust es la seguridad. Las incidencias con la etiqueta type-crash de CPython pasaron de 82 en 2021 a una previsión de 353 en 2026.

Las fases del plan abarcan Python 3.16 en octubre de 2027, 3.17 en octubre de 2028 y 3.18 en 2029 o después. La compatibilidad de Rust con distintas plataformas es ahora "cada vez menos una preocupación", según el equipo. Hewitt también fue directo sobre el resultado final: "sería deshonesto decir que Rust sería opcional para siempre". CPython seguirá siendo "un proyecto de dos lenguajes durante bastante tiempo".

Un nuevo plan para la recolección de basura

Mark Shannon dijo que la recolección de basura, el trabajo de encontrar y liberar la memoria que ya no se usa, ocupa cerca del 11,67 % del tiempo de ejecución de Python. Propuso un híbrido de dos diseños. Un recolector generacional revisa con más frecuencia los objetos nuevos, porque "la mayoría de los objetos mueren jóvenes". Un recolector incremental hace su trabajo en pequeñas porciones en lugar de en una sola parada larga.

La razón son los tiempos de pausa. Shannon situó las pausas incrementales en "decenas de milisegundos", frente a unos 3 segundos con el enfoque generacional. En su diseño, la generación joven empieza con 20 MB. La sala no se puso de acuerdo en un punto: si Python debería ofrecer ajustes al estilo de Java para afinar el recolector.

Después del free-threading: un modelo de concurrencia más seguro

El free-threading es la nueva compilación de Python que puede ejecutar hilos de verdad en paralelo. Tobias Wrigstad, Fridtjof Stoldt y Donghee Na se preguntaron qué viene después. Propusieron Behavior-Oriented Concurrency, un modelo en el que las tareas declaran qué datos necesitan antes de ejecutarse.

Cada dato compartido vive en un "cown", abreviatura de concurrent owner, que solo una tarea puede usar a la vez. Un decorador @when indica los cowns que necesita una tarea. Según los ponentes, este diseño evita los interbloqueos y las condiciones de carrera. Una prueba de concepto, bocpy, ya funciona en Python estable usando subintérpretes. El summit no respaldó ningún enfoque en concreto y se inclinó por seguir investigando.

Tipado, un espacio std y un arranque más rápido

Charla	Ponente	La idea
PEP 827, manipulación de tipos	Michael J. Sullivan	Tipos que calculan otros tipos, como derivar de un solo modelo los tipos ORM de creación y actualización
Espacios de nombres	Pablo Galindo Salgado	Un espacio de nombres std de primer nivel, para que import std.json siempre signifique la biblioteca estándar
Instantáneas de memoria	Hood Chatham	Guardar un intérprete ya iniciado y restaurarlo, lo que reduce el "Hello, world" de Pyodide de 1,406 s a 0,353 s
Soporte de macOS	Ned Deily	Añadir macOS a la PEP 11, la política de soporte de plataformas, y modernizar un instalador que arrastra 25 años de deuda técnica

Sullivan subrayó que "los usuarios no deberían escribir tipos como estos, o solo muy rara vez". Galindo Salgado prometió que el viejo import json seguiría funcionando: "No podemos romper el mundo, eso sería malo." El principal riesgo de las instantáneas es la seguridad. Una semilla de hash que debería ser aleatoria en cada ejecución quedaría congelada y compartida.

Qué significa esto para los desarrolladores

Aquí todavía no hay nada decidido. El summit es una discusión, y cada cambio sigue necesitando una PEP, el proceso formal de propuestas de Python. Lee estos informes como un mapa de hacia dónde van las próximas versiones.

Si compilas CPython desde el código fuente, empieza a revisar lo de Rust. Eso incluye distribuciones de Linux, placas embebidas y plataformas poco comunes. Las propias palabras de Hewitt dicen que Rust no seguirá siendo opcional para siempre. Comprueba que existe una cadena de herramientas de Rust para cada plataforma en la que publicas, antes de que el módulo zlib lo haga importante.

Deja de poner a tus archivos locales nombres de módulos de la biblioteca estándar. Un archivo llamado json.py o random.py en tu proyecto ya puede tapar el módulo real hoy. El espacio de nombres std pretende resolver ese problema, pero elegir bien los nombres lo resuelve ya.

Si tu servicio sufre pausas largas de recolección de basura, sigue el trabajo de Shannon. No construyas todavía ajustes a su alrededor, porque el summit no se puso de acuerdo en si debe haber ajustes.

Los autores de bibliotecas deberían leer la PEP 827. Los mantenedores de ORM y frameworks son su público. Los desarrolladores de aplicaciones se beneficiarán sobre todo sin escribir esos tipos ellos mismos.

Prueba bocpy si escribes Python concurrente. Funciona en el Python actual, y los comentarios de ahora influyen en lo que el equipo del núcleo decida construir.