Python 3.15 es 140 veces más rápido: 5 chistes sobre Python que ya no funcionan

Python 3.15 es 140 veces más rápido. Y es verdad.

Instalas la nueva versión, ejecutas un script que antes tardaba diez segundos y miras el cronómetro.

Nueve coma siete.

No, nadie te ha mentido. Es que llevan veinte años contando el mismo chiste sobre Python: «es lento». Y esta vez Python respondió como sabe hacerlo: con precisión, sin fanfarria y, en algunos sitios, multiplicado por 140.

Python ha ido coleccionando chistes con los años. Que es lento. Que sus hilos son de adorno. Que te da tiempo a hacerte un café mientras arranca un script. Que los mensajes de error parecen acertijos. Que cualquier cosa fuera del ASCII básico se convierte en un galimatías en cuanto abres un archivo en Windows. Y la joya de la corona: «Python es el segundo mejor lenguaje para todo».

Lo divertido es esto: en los últimos tres años —Python 3.13, 3.14 y el recién salido 3.15— el lenguaje ha ido despachando metódicamente casi todos. Vamos uno por uno.

Chiste n.º 1. «Python es lento» → velocidad de Python 3.15 y el JIT

El clásico: mientras Python sigue dando vueltas en un bucle, el programa en C ya compiló, terminó y se fue a casa.

Ahora veamos de dónde salen esas 140 veces. Una ejecución independiente de pyperformance —el conjunto estándar de benchmarks para CPython— comparó Python 3.14.8 y 3.15.0 en dos equipos con Windows 11. El récord se lo llevó la prueba de codificación Base32: unas 140 veces más rápido en un portátil con Intel Core i3 y 135 en un AMD Ryzen 9.

En pocas palabras: Base32 es una forma de escribir cualquier secuencia de bytes usando solo las letras A–Z y los dígitos 2–7, para que puedan viajar como texto plano. Te lo cruzas más a menudo de lo que crees: la clave secreta que escaneas como código QR en Google Authenticator se guarda en Base32.

El truco es sencillo. En 3.15, Base32 se reescribió en C: antes daba vueltas en un bucle de Python puro, ahora ejecuta código compilado. El What's New in Python 3.15 oficial lo llama, con toda modestia, una aceleración de «dos órdenes de magnitud». Ascii85 y Base85, que viven, entre otros sitios, dentro de los PDF, se aceleraron entre 57 y 69 veces. Base64, entre 2 y 3 veces.

Tu script, claro, no va a ir 140 veces más rápido. Pero una prueba típica del mismo conjunto ganó un 17–18%, y lo que más mejoró fue JSON, las expresiones regulares y las plantillas. Gratis. No cambias ni una línea: solo instalas la nueva versión. Hay gente que se pasa semanas optimizando código por mejoras así.

Y lo más gordo: el JIT por fin se ha puesto las pilas.

En pocas palabras: un compilador JIT (Just-In-Time) es la parte del intérprete que, mientras tu programa se ejecuta, encuentra el código que más se repite y lo convierte en instrucciones de máquina. Un intérprete normal vuelve a recorrer el bytecode cada vez. El JIT hace ese trabajo una sola vez y luego simplemente ejecuta el resultado.

En Python 3.13 el JIT era más bien un pago a cuenta del futuro. En 3.15 recibió una revisión a fondo y, según las cifras oficiales, da +7–8% en Linux y +11–12% en Mac con Apple Silicon. Miguel Grinberg, autor del conocido Flask Mega-Tutorial, ejecuta las mismas pruebas de Python puro en cada versión: en sus números, el JIT aceleró el código 1,20–1,28 veces. El JIT sigue siendo experimental y se activa a mano con la variable PYTHON_JIT=1, pero la dirección está clara.

¿Ha alcanzado Python a C? No, y tampoco lo pretende. Pero al chiste de «lento» ya le está entrando la tos.

Chiste n.º 2. «Los hilos de Python son de adorno» → Python sin GIL

Tienes ocho núcleos. Lanzas ocho hilos. Python trabaja en un núcleo y se comporta como si ese hubiera sido el plan desde el principio.

La culpa es del GIL. En pocas palabras: el GIL (Global Interpreter Lock) es un bloqueo que hace que el Python normal ejecute código en un solo hilo en cada momento, da igual cuántos núcleos tenga tu CPU. Durante veinte años fue el argumento estrella de cualquier debate «Python contra todos».

Así fue la cosa. Python 3.13 trajo una build experimental en la que el GIL se puede desactivar. Python free-threaded, o Python sin GIL, es una build aparte del intérprete en la que los hilos se ejecutan de verdad en paralelo en distintos núcleos. En 3.14 pasó a tener soporte oficial y su coste en código de un solo hilo bajó al 5–10%. Y aquí llega la recompensa: en las pruebas de Grinberg con 3.15, la build free-threaded calculó números de Fibonacci en cuatro hilos más de cuatro veces más rápido que la normal.

Más de cuatro veces más rápido. Simplemente porque los hilos por fin trabajan en paralelo.

Un detalle: es un intérprete aparte. Los instaladores oficiales de python.org para Windows y macOS pueden instalarlo junto al normal (en macOS, con 3.15 se instala por defecto), pero el comando python a secas sigue lanzando la build con GIL. Puedes comprobar cuál estás usando con una sola línea:

import sys
print(sys._is_gil_enabled())   # False significa que el GIL está desactivado

Al chiste de veinte años le quedan pocas versiones de vida.

Chiste n.º 3. «Te da tiempo a hacer café mientras arranca un script» → lazy imports

Una herramienta de línea de comandos que solo tiene que mostrar --help se queda pensando un par de segundos. Porque al arrancar carga obedientemente pandas, requests y veinte módulos más que --help no necesita para nada.

Python 3.15 añade los lazy imports. En pocas palabras: un lazy import es un import en el que el módulo no se carga en la línea import, sino la primera vez que de verdad lo usas. Se activa con la palabra clave lazy:

lazy import json
lazy from pathlib import Path

print("Iniciando...")                # json y pathlib todavía no se han cargado

data = json.loads('{"ok": true}')    # json se carga justo ahora

Un lazy import es como una visita que espera en el coche, abajo, y solo sube cuando la llamas por su nombre. Si nadie la llama, nadie tiene que ponerle un plato en la mesa.

Según los autores de la PEP 810, las herramientas de línea de comandos pueden arrancar un 50–70% más rápido, y el consumo de memoria en cargas reales baja un 30–40%. No es un juguete de laboratorio: Meta lleva mucho tiempo usando lazy imports en los servidores de Instagram, y entre los autores de la propuesta hay ingenieros de allí.

Tus pausas para el café están a punto de acortarse bastante.

Chiste n.º 4. «Los mensajes de error de Python son acertijos» → mensajes de error más inteligentes

Durante veinte años la rutina fue la misma: te sale un error, lo pegas en un buscador, lees tres respuestas en Stack Overflow y pruebas la cuarta. Las tres últimas versiones de Python decidieron que nadie debería vivir así.

¿Tu archivo se llama random.py y dentro tiene import random? Antes esto acababa con un misterioso «module has no attribute randint» y media hora de sufrimiento. Desde 3.13, Python te lo dice sin rodeos: tu archivo se llama igual que un módulo de la biblioteca estándar, cámbiale el nombre.

¿Una errata en whille True:? Desde 3.14, Python te pregunta: «Did you mean 'while'?».

Y 3.15 se ha vuelto directamente perspicaz:

AttributeError: 'list' object has no attribute 'push'. Did you mean '.append'?
AttributeError: 'dict' object has no attribute 'put'. Use d[k] = v.

La primera línea es un saludo personal para quien viene de JavaScript. La segunda, para quien viene de Java. El intérprete te reconoce por el acento.

Y un agradecimiento especial a 3.13 por el nuevo REPL: errores en color, edición multilínea y, para salir, ahora basta con escribir exit. Sin paréntesis. Toda una generación que buscó en Google «cómo salir de Python» justo después de «cómo salir de Vim» por fin puede respirar tranquila.

Chiste n.º 5. «¿Eñes y tildes en Windows? Suerte» → UTF-8 por defecto

Si alguna vez has escrito Python en Windows, te sabes esta línea de memoria:

UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 12

Antes de 3.15, open("file.txt") sin una codificación explícita usaba la codificación del sistema, y en Windows normalmente no es UTF-8. Bastaba una comilla tipográfica pegada desde Google Docs para tumbar el script, y «año» se convertía en silencio en «año». En 3.15, UTF-8 es el valor por defecto en todas partes. Una de las preguntas más habituales de quien empieza simplemente desaparece.

Si tu código también tiene que funcionar en versiones anteriores, sigue siendo mejor escribir encoding="utf-8" de forma explícita. «Explícito es mejor que implícito» viene del Zen de Python, y con el Zen no se discute.

Extra: frozendict, t-strings y otras pequeñas victorias

Nunca fueron chistes, pero son demasiado buenas como para saltárselas.

frozendict (3.15, PEP 814). frozendict es un diccionario inmutable: lo creas una vez y después ya no puedes cambiarlo. La lista tiene un hermano inmutable, la tupla; el conjunto tiene frozenset. El diccionario esperó más de treinta años para tener el suyo:

config = frozendict(host="localhost", port=8000)
config["port"] = 9000   # TypeError: no se puede cambiar

Antes, la inmutabilidad se garantizaba con un comentario # ¡¡¡NO TOCAR!!!. Ahora es el propio intérprete el que protege tu configuración, incluso de ti a las 3 de la madrugada.

Desempaquetado en list comprehensions (3.15). Una lista de listas se aplana sin ese doble bucle que media humanidad tiene que leer dos veces:

flat = [*L for L in [[1, 2], [3, 4], [5]]]   # [1, 2, 3, 4, 5]

except sin paréntesis (3.14). except TimeoutError, ConnectionRefusedError: — un detalle pequeño, pero de los que se agradecen.

t-strings (3.14, PEP 750). Las t-strings son parientes de las f-strings que devuelven una plantilla en lugar de una cadena terminada. Las bibliotecas pueden procesar de forma segura los valores sustituidos antes de que acaben convertidos en una inyección SQL.

El perfilador Tachyon (3.15). Se engancha a un programa que ya está en marcha y te muestra dónde va lento, casi sin ralentizarlo. No como el viejo cProfile, que funcionaba como un termómetro que te sube la fiebre. Para lanzarlo con un flame graph ya listo:

python -m profiling.sampling run --flamegraph -o profile.html script.py

Y para un proceso que ya está en marcha: python -m profiling.sampling attach más el ID del proceso (vas a necesitar permisos de administrador).

Por qué esto importa más que las 140 veces

Suma las tres versiones y te sale una imagen que es fácil pasar por alto detrás de los titulares sobre benchmarks.

Python ya es el lenguaje principal de la IA y del trabajo con datos. La gente lo adoraba porque se escribe rápido y lo aguantaba porque se ejecuta lento. Ahora está borrando metódicamente la segunda mitad de esa frase: el JIT, hilos sin GIL, arranque rápido, mensajes de error claros.

Si estás aprendiendo Python, es la mejor noticia que podías recibir. Estás invirtiendo en un lenguaje que se hace más fuerte cada año. El código que hoy escribes en tus ejercicios de práctica mañana podría estar funcionando en un servicio multihilo con JIT, y no vas a tener que cambiar de lenguaje para ganar velocidad.

Eso sí, apréndelo tal como es ahora. Los asistentes de IA se formaron con montañas de código escrito antes de 3.15: sin lazy import, sin frozendict y con montones de llamadas a open() sin codificación. El modelo te escribirá código «como se hacía antes». Saber cómo se hace ahora es tu ventaja.

Y sí, las novedades se aprenden en una tarde. Para entender por qué Base32 reescrito en C se aceleró 140 veces y tu script no, necesitas los fundamentos: cómo funciona el intérprete, qué es el bytecode y por qué un bucle en Python puro es más lento que uno en C. Hemos ordenado qué aprender y en qué orden en nuestra hoja de ruta del desarrollador Python para 2026. Las versiones cambian. Los fundamentos rinden intereses.

Chuleta: novedades de Python 3.13, 3.14 y 3.15

Preguntas frecuentes sobre Python 3.15

¿De verdad Python 3.15 es 140 veces más rápido?

Solo en una prueba: la codificación Base32, que se reescribió de Python puro a C. Una prueba típica del conjunto pyperformance ganó un 17–18%, y si dejas fuera las pruebas de codificación, la mejora media ronda 1,2 veces. Lo más probable es que tu código, sin tocarlo, gane en porcentajes, no en múltiplos.

¿Cuándo salió Python 3.15?

El 9 de octubre de 2026. Las nuevas versiones de Python salen una vez al año, cada octubre.

¿Cómo activo el JIT en Python 3.15?

Con una variable de entorno antes de lanzar el script: PYTHON_JIT=1 python script.py. Las builds oficiales para Windows y macOS ya incluyen el JIT, pero viene desactivado. Sigue siendo experimental y da +7–8% en Linux x86-64 y +11–12% en Mac con Apple Silicon.

¿Cómo instalo Python sin GIL?

Los instaladores oficiales de python.org para Windows y macOS pueden instalarlo junto a la versión normal, y en macOS, con 3.15, se instala por defecto. Para Linux y para compilar desde el código fuente hay una guía en la documentación. Para comprobarlo, ejecuta sys._is_gil_enabled(): si devuelve False, tus hilos trabajan en paralelo.

¿Vale la pena actualizar a Python 3.15?

• Si estás aprendiendo Python — sí, instala 3.15. Las nuevas pistas en los errores te van a ahorrar más de una tarde.
• Si tienes un proyecto personal — adelante también, solo comprueba que las bibliotecas que necesitas ya son compatibles con 3.15.
• Si tienes código en producción — espera a las builds de tus dependencias clave y a las primeras versiones de corrección de errores. De momento, no actives el JIT en producción.

El último chiste

Solo un chiste de la lista sigue en pie: «Python es el segundo mejor lenguaje para todo».

Pero con cada versión, la palabra «segundo» suena un poco más bajito.

Los chistes sobre Python caducan antes que el propio Python. Buen momento para aprenderlo.