Mis colegas de Python están a punto de recibir algo que nosotros dejamos de notar allá por PHP 5.3: código que se carga solo cuando lo tocas. Python 3.15 aterriza el 1 de octubre con el PEP 810, imports perezosos explícitos, y leer la especificación fue como hojear las fotos de bebé de Composer. Así que dejo clara mi postura desde ya: la nueva palabra clave estará bien, el interruptor global le hará daño a alguien, y la diferencia entre ambos se reduce a una regla que nuestro ecosistema interiorizó hace tanto tiempo que olvidamos que alguna vez fue una regla.

python -X importtime -c "import pandas"

Primero la mecánica. El steering council aceptó el PEP 810 por unanimidad el 3 de noviembre de 2025, cuatro votos con la abstención del coautor Pablo Galindo Salgado, y la release candidate 2 salió el 1 de septiembre. Escribes lazy import pandas o lazy from json import dumps, el nombre recibe un placeholder y Python realiza el import real solo cuando ese placeholder se usa por primera vez. Cualquier desarrollador de PHP reconoce la silueta a primera vista. Es spl_autoload_register disfrazado de soft keyword.

Aquí va el porqué el autoloading nunca nos mordió como en teoría podría haberlo hecho. PSR-4 venía acompañado de una regla no escrita: un archivo que define una clase no hace nada más. Sin efectos secundarios, solo una declaración. Ese archivo puede cargarse ahora o dentro de diez minutos y el programa no nota la diferencia. Los módulos de Python son lo contrario por diseño. Importar uno lo ejecuta de arriba abajo, y las bibliotecas maduras se apoyan en ese momento para registrar plugins y hacer monkey-patching. Difiere esas cargas y habrás reordenado efectos secundarios en todo el proceso.

Los autores del PEP 810 claramente lo entienden, y por eso la palabra clave está bien cercada: solo a nivel de módulo, prohibida dentro de funciones, cuerpos de clase, bloques try e import *. La prohibición en bloques try es la que más escuece, porque descarta el clásico baile de dependencias opcionales donde intentas importar pyarrow, capturas ImportError y recurres a un centinela None. Con el diferimiento, el fallo aparecería en el primer uso, mucho después de que la cláusula except de turno terminara de no hacer nada, así que la prohibición es ingeniería honesta. Los premios de consolación tampoco están mal: cuando un import diferido explota, la cadena de excepciones apunta tanto al sitio de la declaración como al acceso que lo disparó, y una carga fallida se reintenta en el siguiente toque.

Sobre las ganancias prometidas, mantén el escepticismo caliente. El PEP cita reducciones de arranque del 50 al 70 por ciento y ahorros de memoria del 30 al 40 por ciento sin anclar ninguna cifra a una base de código con nombre; el único caso atribuido, el trabajo de Christian Tismer en PySide, se queda en un 10 a 20 por ciento. Instagram de Meta y Hudson River Trading aparecen mencionados como usuarios en producción, sin números adjuntos. La materia prima, eso sí, es real. En CPython 3.11 un import pandas en caliente cuesta unos 250 milisegundos, NumPy solo ronda los 64, y un intérprete vacío arranca en menos de 3. Que un cuarto de segundo importe depende por completo de cuánto vive el proceso. En una CLI que alguien ejecuta todo el día, importa mucho. En un worker que arranca una vez y mastica una cola durante una semana, se esfuma, por la misma razón por la que Laravel Octane vuelve irrelevante el coste de arranque del framework pagándolo exactamente una vez.

Ahora la parte que merece un ticket de revisión de cambios. El PEP 810 trae tres modos, normal, all y none, configurables mediante sys.set_lazy_imports(), el flag -X lazy_imports o la variable de entorno PYTHON_LAZY_IMPORTS, más un hook de filtrado en sys.set_lazy_imports_filter() y un conjunto sys.lazy_modules que rastrea los nombres que aún no se han materializado. El modo all difiere todos los imports del proceso, incluidos los de dependencias cuyos mantenedores nunca probaron el diferimiento y que en algunos casos dependen directamente de la ejecución en tiempo de import. El PEP les dice a esos mantenedores cuál es el arreglo: dejar de hacer trabajo de registro al importar y exponer una función init explícita en su lugar. Esa es precisamente la disciplina que a PHP le costó años y un gestor de paquetes universalizar, y Python la está pidiendo con carácter retroactivo mientras le entrega a cada equipo de ops una sola variable que asume que el trabajo ya está hecho.

Así que aquí es donde aterrizo, tras conceder las partes genuinamente buenas. La palabra clave opt-in está bien diseñada, y marcar los imports pesados al principio de un punto de entrada de CLI, y luego comprobar la diferencia con -X importtime, es dinero gratis que deberías cobrar. Pero trata el modo all como tratarías cambiar el autoloader en una tienda en producción, y mantenlo lejos de cualquier job que escriba datos. Un import ansioso que falla mata el proceso antes de que empiece el trabajo, un reinicio limpio. Uno diferido puede fallar cuando las filas ya salieron por la puerta, y ninguna gráfica de arranque en frío justifica heredar esa limpieza.

Lo que me lleva a ti. Imagina que mañana nos llegara la imagen especular: una variable de entorno que volviera perezoso cada require dentro de vendor/, con efectos secundarios incluidos. ¿La activarías en una máquina de producción a cambio de un arranque más rápido? Si tu respuesta es no, quiero saber qué evidencia te haría cambiar de opinión, porque en algún rincón de tu empresa un equipo de Python está a punto de hacer exactamente esa apuesta.