Python 3.15.0 llega con JIT más rápido y UTF-8 por defecto

Python 3.15.0 sale a producción con 5.643 commits de 1.012 contribuyentes

Python 3.15.0 ya es la versión estable, publicada el 9 de octubre de 2026. Es el resultado de 5.643 commits firmados por 1.012 contribuyentes y consolida varias líneas de trabajo que la comunidad venía empujando desde 3.13 y 3.14: el compilador JIT experimental se vuelve realmente útil, UTF-8 pasa a ser la codificación por defecto, llegan dos tipos nuevos al lenguaje (frozendict y sentinel), y se introduce la posibilidad de hacer imports perezosos declarativos. Si tu stack es Python, esta release te toca el bolsillo y el rendimiento a la vez.

El JIT pasa de "experimental" a una mejora medible

El equipo de CPython ha renovado el compilador JIT que debutó como experimental en 3.13. Según el anuncio oficial, en Linux x86-64 ofrece una mejora del 7-8% en media geométrica sobre el intérprete estándar, y en macOS sobre AArch64 alcanza un 11-12% de speedup frente al intérprete con tail-calling. Son cifras oficiales del propio release.

Para poner el salto en contexto, los benchmarks de InfoWorld sobre la alpha 3.15 mostraban que el n-body cae de 7,6 segundos sin JIT a 4,2 segundos con JIT en la misma máquina, una mejora cercana al 45% en un workload clásico de cálculo numérico. PyPy sigue siendo más rápido en bruto (0,7 segundos en el mismo test, según InfoWorld), pero CPython con JIT y sin GIL ya gana a PyPy en escenarios I/O-bound gracias al paralelismo real entre hilos. El artículo de InfoWorld lo resume así: "as yet, there is no build of CPython that enables the JIT and uses free threading, but such a version is not far away".

UTF-8 por defecto: el cambio que más vas a notar (PEP 686)

PEP 686 convierte a UTF-8 en la codificación por defecto del intérprete. Hasta 3.14, abrir un archivo de texto sin encoding explícito dependía de la configuración regional (con todas las sorpresas que eso trae en Windows y en servidores Linux minimalistas). A partir de 3.15, "hola".encode() devuelve bytes UTF-8 sin sorpresas y open("datos.txt") lee UTF-8 sin más. Para equipos en LATAM y España es un alivio concreto: se acabaron los UnicodeDecodeError al cruzar archivos entre máquinas con locales distintos.

frozendict y sentinel: dos tipos nuevos que tu código va a querer

PEP 814 añade frozendict, un diccionario inmutable que puede usarse como clave de caché o dentro de sets. Es el equivalente a frozenset pero para mappings, y llega para resolver el clásico workaround de subclases de dict que bloqueaban la asignación. PEP 661 añade sentinel, un objeto único pensado para representar "ausencia de valor" sin tener que crear sentinels ad-hoc en cada módulo (_SENTINEL = object()), que es uno de los patrones más repetidos en bibliotecas de configuración, parsing y data pipelines.

Imports perezosos declarativos: el startup time importa (PEP 810)

PEP 810 introduce la sintaxis para hacer imports perezosos de forma explícita. La motivación es directa: en CLIs, lambdas, notebooks y workloads serverless, el tiempo de arranque de Python se come buena parte del budget total, y la mayoría de los imports pesados solo se usan en una rama del código. Con imports perezosos declarativos, el intérprete puede diferir la carga hasta que se necesita, sin el hack actual de mover el import dentro de la función. Para founders con funciones en AWS Lambda, Vercel o Cloud Run, es un recorte tangible de cold starts.

Tipos más expresivos para evitar bugs en producción

Tres PEPs cambian la forma de anotar tipos:

• PEP 728: TypedDict con extras tipados — ya puedes anotar TypedDict diciendo que las claves no listadas explícitamente tienen un tipo concreto en sus valores. Cierra un agujero muy común al integrar APIs externas.
• PEP 747: TypeForm — permite anotar el tipo en sí mismo, no un valor de ese tipo. Es la pieza que faltaba para que decoradores y factories tipen correctamente sus argumentos de tipo.
• PEP 800: Disjoint bases — el sistema de tipos entiende que dos bases no comparten instancias, lo que reduce TypeError en runtime en jerarquías complejas.

Tachyon y PEP 799: profiling de alta frecuencia en la librería estándar

PEP 799 añade un paquete dedicado a organizar herramientas de profiling y, dentro de él, Tachyon, un profiler estadístico de alta frecuencia. Para equipos que depuran latencia en pipelines de datos o backends de ML, tener un sampler serio en la librería estándar significa no tener que añadir py-spy o scalene como dependencia obligatoria para entender dónde se va el tiempo.

C API: free-threading ya es estable y los binarios lo activan por defecto

PEP 803, 820 y 793 estabilizan el ABI para builds free-threaded (sin GIL). Los binarios oficiales de macOS ahora instalan soporte free-threading por defecto, y los binarios de Windows 64-bit adoptan el tail-calling interpreter también por defecto. Esto es relevante para quien ejecuta Python en código nativo o en extensiones C: el camino a paralelismo real deja de ser opt-in y empieza a ser el camino recomendado.

El interim de 3.15.0rc3, publicado el 2 de octubre según un análisis del blog oficial, ya había incorporado 156 bug fixes de 82 contribuyentes desde rc2. El lanzamiento final se retrasó una semana precisamente para incluir un fix de último momento en lazy-import, lo que muestra lo serio que se tomó el equipo el camino hacia la release.

El contexto del lenguaje: Python sigue siendo #1, pero ya no crece

El TIOBE Index de septiembre de 2026 sitúa a Python en el primer puesto con 17,76%, pero con una caída gradual que arrastra todo el año. C baja a 10,28%, C++ sube a 8,67% y Java cae a 7,54%, según los datos reportados por TechRepublic. Rust cumple su tercer mes consecutivo en el top 10 (1,34%) y Julia se acerca al top 20 (0,74%, en el puesto 21).

Lectura para founders: Python sigue dominando en uso general, pero la conversación sobre rendimiento se está desplazando hacia Rust y hacia runtimes con paralelismo real. La apuesta de CPython por JIT + free-threading es, justamente, la respuesta a esa presión.

La advertencia: macOS 27.0 + tkinter se cuelga

El release notes oficial llama la atención sobre un bug en macOS 27.0: las aplicaciones que usan tkinter (incluido IDLE) pueden colgarse al abrir diálogos del menú, mostrando el típico beach ball y exigiendo Force Quit. El equipo atribuye el problema a un cambio de comportamiento del propio sistema operativo que afecta a todas las versiones actuales de Tk. Se puede seguir en el issue #158053 del repositorio. Si dependes de Tk, el consejo oficial es posponer la actualización a macOS 27.0 hasta que haya workaround.

Easter egg: "whatsnewt", el juego de texto para aprender 3.15

Barry Warsaw publicó "whatsnewt", un mini juego de texto en TUI con 18 puzzles que cubren una a una las novedades de 3.15. Se ejecuta con uvx --python 3.15 whatsnewt y verifica tus respuestas con pyrefly como type checker. Es la forma más rápida de tocar las novedades sin leer la spec entera.

Qué significa esto para tu startup

1. Audita tu runtime antes de saltar a 3.15. Si tu aplicación corre en serverless o en CLIs con cold-start sensible, PEP 810 (lazy imports) es el primer experimento a hacer. En un día puedes aislar imports pesados, marcarlos como perezosos y medir la mejora de arranque. Si dependes de extensiones C, valida que tu wheel esté compilada para el ABI free-threaded (PEP 803/820/793) antes de activar el flag.

2. Deja de pelearte con UTF-8. Si todavía tienes encoding="utf-8" clavado en cada open() por costumbre, PEP 686 te permite limpiarlo. Es un cambio de bajo riesgo, alto beneficio de mantenibilidad y que elimina bugs silenciosos cuando un archivo cruza máquinas con locales distintos. Aprovéchalo en nuevos archivos; en legacy, migra por etapas.

3. Usa frozendict y sentinel como mejora de calidad. Son dos PEPs (814 y 661) que probablemente ya te ahorren una clase entera de bugs en data pipelines y configs. Adoptarlos en código nuevo cuesta cinco minutos y elimina el patrón MY_SENTINEL = object() que todo el mundo reinventa mal.

4. Planifica el ciclo de upgrade. Las wheels para 3.15 empiezan a llegar a PyPI ya, pero el ecosistema C-extension va con retraso. Mantén 3.14 como versión de producción durante las próximas 4-6 semanas y mueve 3.15 primero a staging y a jobs batch no críticos. Si trabajas en macOS, espera a que tkinter tenga workaround antes de subir a 27.0.

Fuentes

• Python 3.15.0 Release
• Python 3.15.0rc3 Released, Final Version Postponed to October 9
• CPython vs. PyPy: Which Python runtime has the better JIT?
• TIOBE Index for September 2026: Python Drops Below 18% as Julia Nears Top 20