Python 3.10 tras el fin de su vida útil: localizar intérpretes y reconstruir entornos

Qué es

Estado al 25 de octubre de 2026: la Guía del desarrollador de Python incluye Python 3.10 en su tabla de versiones sin soporte, con fecha de fin de vida útil del 1 de octubre de 2026. Su definición de esta fase congela el ciclo de versiones y no permite más cambios. Volver a consultar esa tabla y la rama elegida como sustituta antes de migrar; un número de parche posterior de 3.10 no establece un nuevo período de soporte. Ciclo de vida del proyecto original.

Por qué importa

La unidad de inventario útil es una aplicación y su intérprete real. Comprobar solo la shell de un administrador deja sin examinar los lanzadores de servicios, las tareas programadas, los ejecutores de compilaciones y las cargas de trabajo en contenedores. El siguiente flujo de trabajo es una propuesta operativa para localizar y sustituir esas dependencias.

Los entornos de Python tienen un intérprete base y sus propios paquetes. Su documentación los considera desechables y no aptos para copiarlos entre ubicaciones. Recrearlos a partir de las dependencias declaradas en lugar de trasladar un entorno antiguo al despliegue de sustitución. Entornos virtuales.

Cómo aplicarlo

• Empezar por las definiciones de servicios, las programaciones de tareas, los directorios de aplicaciones y los archivos de construcción de contenedores. Para cada intérprete de aplicación cuya inspección esté autorizada, ejecutar el siguiente diagnóstico, sustituyendo python por su ruta absoluta. Registrar el responsable de su carga de trabajo y la ubicación del despliegue. Los campos documentados de sys identifican el ejecutable, la versión del lenguaje y los prefijos del entorno. Campos del intérprete.

  python -c 'import sys; print(sys.executable, sys.version_info[:3], sys.prefix, sys.base_prefix)'
  

• Inspeccionar el archivo pyvenv.cfg de cada entorno, así como la receta de construcción y el inventario de ejecución de cada imagen. Comprobar tanto las etapas de construcción como las de ejecución. Tratar un intérprete ausente o inaccesible como una carencia del inventario. Para los paquetes proporcionados por una distribución, obtener las pruebas de soporte del distribuidor específicas del paquete antes de clasificar su soporte por separado del proyecto original.

• Seleccionar una rama que cuente con soporte tanto del proyecto original como de las dependencias de la aplicación. Python 3.12 es un ejemplo con soporte en la tabla de ciclo de vida, no un destino obligatorio. Con ese intérprete instalado en un entorno de prueba, crear un entorno nuevo mediante python3.12 -m venv .venv-next y, después, restaurar las dependencias revisadas del proyecto con su procedimiento de instalación existente.

• Revisar las notas de versión de todas las ramas intermedias. Para la transición a 3.12, comprobar las importaciones de los módulos eliminados imp y distutils y las suposiciones de que setuptools se instala de forma predeterminada. Actualizar el código afectado o las declaraciones de dependencias. Estos son cambios de compatibilidad documentados, no una clasificación de fallos de migración basada en mediciones. Cambios en Python 3.12.

• Ejecutar .venv-next/bin/python -m pip check y las pruebas de la aplicación, incluidos el arranque y tareas representativas. El comando de pip comprueba la compatibilidad de las dependencias; el comportamiento de la aplicación requiere pruebas independientes. Reconstruir las imágenes, actualizar las rutas de lanzamiento, desplegar mediante el proceso habitual de cambios y repetir el diagnóstico del intérprete en la carga de trabajo desplegada. pip check.

Trampas

No sobrescribir el intérprete del sistema de una distribución para reparar una aplicación. Mantener un despliegue de reversión probado mientras se valida el sustituto y asignar a cualquier retorno temporal a 3.10 un responsable y una fecha de retirada. Dar por terminada la migración solo cuando también se hayan contemplado las rutas de lanzamiento antiguas, las referencias a imágenes y las definiciones de tareas inactivas. El fin de la vida útil es un hallazgo relativo al soporte, no una prueba de que un sistema haya sido comprometido.