Python 3.15 RC2: comprobar paquetes y UTF-8 antes de migrar

Actualizado el 15 de septiembre de 2026. Python 3.15.0rc2 llegó el 1 de septiembre: es una versión preliminar, no recomendada para producción. Python 3.15.0rc2 (2026-09-01) La versión final está prevista para el 1 de octubre, sin garantía. PEP 790 Los desarrolladores y pequeños equipos de TI pueden preparar sus scripts con copias de los datos. Describimos un procedimiento, no una prueba de software realizada por nosotros.

Qué conviene comprobar

Python 3.15 activa el modo UTF-8 por defecto. PEP 686 Revisa especialmente las importaciones CSV, los textos con acentos y las salidas de programas externos. Actualizar no convierte automáticamente los archivos. Recomendamos comparar operaciones reales con copias de prueba, no solo comprobar que la aplicación arranca.

Requisitos y límites

Necesitas un intérprete de prueba Python 3.15 fiable e instalado por separado, una copia del proyecto y las dependencias documentadas. El sistema operativo, la arquitectura y la variante del intérprete deben corresponder al destino previsto. No sustituyas el Python del sistema ni el entorno productivo. Una venv separa paquetes Python Python: venv, pero no es un aislamiento de seguridad: el código de prueba no debe acceder a cuentas, bases de datos o servicios de envío de producción. Usa solo paquetes autorizados y datos de prueba no confidenciales.

Seis pasos en el proyecto de prueba

  1. Registra la referencia: versión actual de Python, revisión del proyecto, versiones de paquetes y resultados esperados. Guarda código y datos de entrada fuera del nuevo entorno; conserva la instalación que funciona.

  2. Confirma el intérprete con el comando de versión adecuado. Debe mostrar la versión 3.15 de prueba elegida, en esta fecha 3.15.0rc2. Si aparece otra, aclara primero la ruta de instalación.

  3. Crea un entorno nuevo dentro de la copia del proyecto, usando un directorio .venv315 que aún no exista. Después invoca directamente su intérprete. No hace falta activarlo ni cambiar la política de ejecución de PowerShell.

  4. Instala las dependencias con el procedimiento habitual del proyecto. Los comandos suponen un requirements.txt revisado; para otros formatos de bloqueo de versiones utiliza la herramienta existente. pip check comprueba la coherencia de dependencias pip check, no el comportamiento de la aplicación.

  5. Compara funciones: ejecuta las pruebas existentes y una importación/exportación representativa sobre copias. Compara número de filas, caracteres especiales, importes y archivos de salida con el entorno anterior. Arrancar correctamente no basta.

  6. Documenta los hallazgos: ruta del intérprete, versión, paquetes y pasos reproducibles. Distingue paquetes ausentes, fallos de instalación y resultados distintos. Retira rutas privadas y datos de los informes públicos.

Comandos del entorno separado

Elige solo el bloque de tu sistema. Estos comandos no instalan Python: requieren el intérprete ya verificado. La instalación de paquetes descarga e instala dependencias desde las fuentes configuradas. Ejecútala únicamente en el proyecto de prueba autorizado. pip install

Linux / macOS

python3.15 --version
python3.15 -m venv .venv315
.venv315/bin/python --version
.venv315/bin/python -m pip install -r requirements.txt
.venv315/bin/python -m pip check

Windows / PowerShell

py -3.15 --version
py -3.15 -m venv .venv315
.\.venv315\Scripts\python.exe --version
.\.venv315\Scripts\python.exe -m pip install -r requirements.txt
.\.venv315\Scripts\python.exe -m pip check

Evaluar resultados y volver con seguridad

El éxito requiere el intérprete correcto, instalación satisfactoria, ningún conflicto de dependencias notificado y resultados funcionales coincidentes. Si pip no encuentra un candidato compatible, revisa la versión del paquete, el soporte de Python, la plataforma y la fuente autorizada. No demuestra automáticamente un fallo de Python; no desactives comprobaciones para forzar la instalación. Ante caracteres corruptos o UnicodeError, determina la codificación real del archivo y especifícala en el programa. No etiquetes todos los archivos antiguos como UTF-8 ni sobrescribas originales.

Si surgen problemas, termina la prueba y sigue trabajando con el entorno anterior intacto. Conserva la copia del proyecto y los registros para el diagnóstico. Una futura aprobación productiva requiere la versión final y nuevas pruebas de la aplicación; una prueba RC satisfactoria no las sustituye.

Fuentes y transparencia

Guía editorial basada en fuentes, sin prueba propia de compatibilidad ni rendimiento. Sin enlaces de afiliados ni recomendación de compra. La actualidad procede de la fase RC; no afirmamos que exista un auge general de búsquedas.