Índice de contenidos
Claves de la noticia
- Python 3.15.0 ya está disponible como versión estable, con UTF-8 por defecto, importaciones diferidas y el nuevo tipo frozendict.
- La codificación puede cambiar al actualizar aunque el programa conserve su código; diferir importaciones requiere activar la función.
- Un diccionario congelado puede contener listas modificables: su protección no se extiende automáticamente a los objetos anidados.
Python 3.15 llega este 9 de octubre con cambios que afectan tanto al arranque de las aplicaciones como a la lectura de archivos y al tratamiento de configuraciones. El equipo del lenguaje ha confirmado la versión final. Para quienes mantienen programas existentes, la primera decisión es distinguir qué comportamiento cambia al instalarla y qué mejoras necesitan una adaptación deliberada.
Una versión final con cinco años de horizonte
Hugo van Kemenade, responsable del lanzamiento, anuncia en Python Insider una versión construida con 5.643 commits de 1.012 colaboradores frente a Python 3.14. La página oficial ofrece instaladores y archivos fuente. La publicación deja atrás la fase candidata; no significa que todos los paquetes de terceros estén preparados para cada entorno que utilice el lenguaje.
El calendario PEP 790 recoge una tercera candidata el 2 de octubre y la final el día 9. Prevé aproximadamente dos años de correcciones de errores, con entregas cada dos meses, y después tres de actualizaciones de seguridad distribuidas como código fuente. El horizonte previsto termina hacia octubre de 2031. Esa diferencia entre mantenimiento completo y seguridad importa a quien planifique una plataforma que debe durar varios años.
Entre las novedades figuran el perfilador Tachyon, cambios en las interfaces para extensiones y mejoras del compilador JIT experimental. El anuncio también advierte de bloqueos de aplicaciones Tk, como IDLE, en macOS 27.0 al abrir determinados diálogos. Atribuye el problema a un cambio del sistema operativo que puede afectar a distintas versiones de Python: estrenar 3.15 no equivale a corregir ese comportamiento.
UTF-8 cambia la prioridad de las pruebas
La PEP 686 establece UTF-8 como modo predeterminado desde 3.15. Hasta ahora, un programa que omitía la codificación al abrir un archivo podía depender de la configuración regional. El cambio afecta especialmente a Windows y busca reducir diferencias entre plataformas. Sigue siendo posible desactivar el modo mediante PYTHONUTF8=0 o la opción -X utf8=0.
Para un programa que intercambia archivos con aplicaciones antiguas, la pregunta concreta es qué codificación tienen esos datos. Un fichero heredado con tildes o eñes puede necesitar una declaración explícita distinta de UTF-8. La propuesta recomienda localizar dependencias de la codificación implícita con EncodingWarning y probar después el funcionamiento con el nuevo modo. Es una comprobación relevante para automatizaciones en castellano; el idioma por sí solo no determina cómo están almacenados los caracteres.
| Cambio | Activación | Comprobación útil |
|---|---|---|
| UTF-8 | Por defecto | Archivos con codificación implícita |
| Importación diferida | Elección del desarrollador o configuración | Inicialización y primer uso |
| frozendict | Uso del nuevo tipo | Valores anidados modificables |
El contraste entre las propuestas permite fijar una prioridad: la lectura de texto merece revisión antes de activar optimizaciones de arranque. UTF-8 puede alterar un programa intacto; las otras dos novedades de la tabla no sustituyen automáticamente sus importaciones ni sus diccionarios. Esa asimetría ayuda a ordenar una migración sin convertir todas las características del lanzamiento en riesgos equivalentes.
El coste de importar se desplaza al primer uso
La PEP 810 permite marcar importaciones con lazy. En lugar de cargar el módulo al encontrar la instrucción, el intérprete espera hasta que el nombre importado se utiliza. Así, una herramienta con muchas dependencias puede evitar cargar algunas durante una ejecución que no las necesita. La función se introduce de forma gradual y no exige modificar todas las bibliotecas de una aplicación.
La consecuencia requiere revisar más que el tiempo de arranque. La ejecución inicial del módulo también se pospone, incluidos sus efectos secundarios. Si una aplicación dependía de que una importación registrase componentes antes de atender una petición, diferirla cambia cuándo ocurre ese registro. El ahorro procede de evitar o aplazar trabajo, y no garantiza acelerar una operación que finalmente necesita cargar las mismas dependencias.
Por eso una prueba que solo abre la herramienta y comprueba que arranca no cubre la migración: debe recorrer también la función que utiliza por primera vez el módulo diferido. Conviene verificar inicialización y resultado antes de ampliar lazy. Es una consecuencia de la especificación, no un benchmark propio.
Congelar un diccionario no congela su contenido
La PEP 814 incorpora frozendict, un tipo que impide añadir, borrar o sustituir entradas después de crearlo. Conserva el orden de inserción y puede servir para configuraciones compartidas o argumentos de funciones con caché. Para calcular su hash, las claves y los valores deben ser a su vez compatibles con esa operación.
La propia propuesta muestra un diccionario congelado que contiene una lista y modifica esa lista. La inmutabilidad es superficial: protege la asociación entre claves y valores, pero no bloquea las operaciones que admite cada valor. Una configuración con listas anidadas conserva esas listas modificables. Además, frozendict no hereda de dict, por lo que una comprobación de tipo estricta puede necesitar adaptación.
Esta distinción delimita su utilidad: sustituir el contenedor puede prevenir cambios accidentales en sus entradas, pero no basta para compartir una estructura completamente inmutable. Antes de emplearlo como clave de caché o configuración fija, hay que revisar los valores. El documento permite comprobar ambos límites directamente.
Medir el programa que se va a desplegar
Tachyon se integra en profiling.sampling. Su documentación distingue medición de tiempo real y tiempo de CPU, además de otras modalidades. El tiempo real incluye esperas; el de CPU se centra en ejecución activa. Elegir la métrica correcta evita atribuir a cálculo una demora causada por entrada y salida o por una dependencia que se inicializa tarde.
Una migración defendible puede comenzar con archivos reales y recorridos completos de la aplicación, conservar sus resultados y medir después dónde compensa diferir cargas. La conclusión operativa es precisa: actualizar el intérprete, cambiar el momento de inicialización y adoptar contenedores inmutables son decisiones separadas. Python 3.15 ofrece herramientas para las tres, pero cada una exige comprobar una propiedad distinta del programa.
Imagen: ilustración conceptual generada con IA; no representa a miembros del equipo de Python.
