Herramienta de pitón científica moderna en 2026: UV, Ruff y Ty

Comida clave

• UV se ha convertido en el administrador de paquetes de Python predeterminado para la informática científica, de 10 a 100 veces más rápido que PIP, con archivos de bloqueo deterministas que hacen que los flujos de trabajo de investigación sean reproducibles.
• Ruff Reemplaza a Black, iSort, Flake8, PyUpgrade y Autoflake en un solo binario basado en óxido. Scipy, pandas y otras bibliotecas científicas importantes lo usan hoy en día.
• ty (publicado en diciembre de 2025) es de 20 a 100 veces más rápido que myPy y utiliza una garantía gradual que no romperá el código no anotado, ideal para migrar códigos de investigación.
• PyProject.Toml es ahora la única fuente de configuración para toda la cadena de herramientas, reemplazando archivos de configuración dispersos como .flake8, .isort.cfg y mypy.ini.
• Para la computación científica específicamente, la conda sigue siendo necesaria para las dependencias que no son de Python (MPI, CUDA, HDF5) y Pyright sigue siendo la opción de CI más segura hasta que TY alcance la versión 1.0.

Si está ejecutando flujos de trabajo científicos de Python en 2026, su cadena de herramientas ha cambiado fundamentalmente. Los paquetes que utiliza para el cálculo (numpy, scipy, fipy y el resto) son los mismos. Pero la forma en que los instala, administra, pelusa y marca los tipos es diferente de lo que la mayoría de los tutoriales, las guías anteriores y los cuadernos de laboratorio universitarios aún recomiendan.

Astral, la compañía detrás del linter (ruff) más popular de Python, construyó tres herramientas que ahora cubren todo el flujo de trabajo del desarrollador: UV para la gestión de paquetes, ruff para el envio y el formato, y ty para la verificación de tipos. Juntos, reemplazan a pip, venv, black, isort, flake8 y mypy. Son seis herramientas colapsadas en tres, todas configuradas a partir de un solo archivo pyproject.toml.

Este artículo cubre la cadena científica moderna de herramientas Python en 2026. Explica qué hace cada herramienta, por qué ocurrió el cambio y cómo configurar todo, incluidas las peculiaridades y las limitaciones que importan para la computación científica. Si está configurando un nuevo proyecto de simulación, migrando una base de código existente o poniéndonos al día después de la guía «Ecosistema de Python científico» (consulte el artículo #364), esta es la actualización práctica que necesita.

El moderno paisaje de herramientas

Hasta aproximadamente 2024, el flujo de trabajo de Scientific Python Developer se veía así:

• Gestión de paquetes: pip con pip-tools o poesía
• Entornos virtuales: Venv o VirtualEnV
• Administración de versiones de Python: PYENV o PYENV-VirtualEnv
• linting: Flake8, luego PydocStyle, más Pylint para verificaciones de estilo
• Formatear: negro e iSort (y posteriormente, AutoPep8 y PyUpgrade)
• Comprobación de tipo: myPy

Eso significó instalar seis paquetes de Python separados, mantener archivos de configuración separados y esperar a través de pasos de resolución secuenciales. Un simple pip install podría tomar minutos. Ejecución negra, luego isort, luego flake8, luego mypy podría tomar más tiempo.

El cambio comenzó cuando Astral lanzó Ruff en 2023. Ruff se escribió en óxido, diseñado para reemplazar negro, iSort, Flake8, PyUpgrade y Autoflake simultáneamente, y corrió órdenes de magnitud más rápido que las alternativas basadas en Python. Ese éxito en la adopción le dio a Astral el impulso para construir un ecosistema completo: UV para la gestión de paquetes y TY para la verificación de tipos.

A fines de 2025 y principios de 2026, la convergencia estaba completa. El guía científica de desarrollo de Python ahora recomienda oficialmente Ruff para verificaciones de estilo y ty para verificación de tipo. Scipy y Pandas han adoptado Ruff. UV ha superado la poesía en adopción entre los equipos de computación científica. La pila anterior no está muerta, todavía funciona, pero ya no es la predeterminada para nuevos proyectos.

Por qué es importante PyProject.toml

Uno de los mayores cambios prácticos es el modelo de configuración. La antigua configuración de pila dispersa en cinco o más archivos:

• .flake8 Para las reglas de pelusa
• .isort.cfg para la clasificación de importación
• mypy.ini para el comportamiento de verificación de tipo
• setup.cfg para los metadatos del paquete
• pyproject.toml (parcialmente, para sistemas de construcción)

Las herramientas modernas centralizan todo en pyproject.toml. Un solo archivo define el paquete, las dependencias, las herramientas de desarrollo y la configuración de la herramienta. Esto hace que los proyectos sean más fáciles de compartir, clonar y mantener, exactamente lo que necesitan los equipos de investigación cuando publican código o incorporan a nuevos estudiantes.

UV: gestión de paquetes que realmente funciona

uv es un administrador de paquetes basado en óxido construido por Astral. Reemplaza PIP, PIP-Tools, PiPX, PYENV y VirtualEnv en un solo binario rápido. A diferencia de PIP, uv no requiere que Python se instale primero: puede iniciar un intérprete de Python y administrar versiones junto con las dependencias.

Por qué los investigadores están cambiando

Las principales razones por las que los investigadores y desarrolladores eligen uv:

1. Velocidad. uv instala paquetes de 10 a 100 veces más rápido que PIP, principalmente a través de resolución paralela y almacenamiento en caché agresivo. Esto importa en las canalizaciones de CI donde el tiempo de instalación afecta directamente a la respuesta del desarrollador.
2. Archivos de bloqueo. Un solo archivo uv.lock registra versiones resueltas exactas de cada dependencia, incluidas las subdependencias. Comprometer este archivo a Git hace que su entorno sea completamente reproducible, un requisito para las simulaciones publicadas.
3. Gestión de versiones de Python. uv Puede descargar y administrar intérpretes de Python, eliminando la necesidad de herramientas separadas como PYENV.
4. Compatibilidad PIP. Los comandos como uv pip install funcionan con requirements.txt, lo que simplifica la migración de los proyectos existentes.

Configuración de UV

El flujo de trabajo típico para un nuevo proyecto científico de Python se ve así:

# Install uv (curl pipe to sh, cross-platform)
curl -LsSf https://astral.sh/uv/install.sh | sh

# Create a project with a specific Python version
uv init my-simulation --python 3.11
cd my-simulation

# Add core scientific dependencies
uv add numpy scipy matplotlib

# Add domain-specific libraries
uv add fipy mpmath

# Add development tools
uv add --group dev pytest ruff ty

# Generate and commit a lockfile
uv lock
git add pyproject.toml uv.lock
git commit -m "Initial project with pinned dependencies"

uv sync Se instala desde el archivo de bloqueo, asegurando reproducciones deterministas. Cualquiera que clone el repositorio y ejecute uv sync obtiene exactamente las mismas versiones resueltas.

La peculiaridad de compilación de código de bytes

Aquí es donde uv se comporta de manera diferente a PIP, y donde los equipos de computación científica han golpeado muros inesperados.

uv Difiere la compilación de código de bytes a la primera ejecución. Cuando uv instala un paquete, almacena código de bytes precompilado en una caché pero no compila todos los archivos de inmediato. Esto hace que las instalaciones uv sean aproximadamente de 3 a 4 veces más rápidas que PIP. Sin embargo, la primera importación de una biblioteca (especialmente numpy o scipy) puede ser aproximadamente 2,5 veces más lenta que una copia instalada en PIP, porque el código de byte se compila en el momento de la importación.

Para el desarrollo interactivo, esta desaceleración suele ser imperceptible. Para las canalizaciones de CI, los scripts de trabajo de HPC o los servidores de producción que importan Numpy o Scipy en cada ejecución, la peculiaridad importa. La solución es simple: agregue --compile-bytecode a su comando de sincronización.

Contexto del mundo real: el equipo de datos de Plotly documentó este problema exacto después de adoptar uv en producción. Sus servidores de producción vieron importaciones numpy notablemente más lentas hasta que agregaron la bandera. Vea la publicación de Party de Plotly sobre las peculiaridades UV para conocer el desglose técnico completo.

El comportamiento de índice exclusivo

uv Trata --extra-index-url entradas exclusivas de forma predeterminada, después de PEP 0708. Esto significa que si existe un paquete en su índice principal, uv nunca comprobará el índice adicional. Esto protege contra los ataques de dependencia: un actor malintencionado no puede reemplazar un paquete alojado en un índice bien conocido con un espejo comprometido. Pero también rompe las tuberías existentes requirements.txt que dependen de índices adicionales para los paquetes alternativos.

Si su laboratorio usa un índice de paquete privado o un índice compatible con CONDA, deberá configurar explícitamente el index-strategy en pyproject.toml. Sin esa configuración, uv puede no resolver los paquetes que espera encontrar en el índice adicional.

Cuando los rayos UV no son suficientes

uv Administra paquetes de Python e intérpretes de Python. No administra las dependencias del sistema que no son de Python: bibliotecas C y C++, compiladores Fortran, kits de herramientas MPI, CUDA, HDF5, FFTW o bibliotecas de gráficos.

Para esas dependencias, Conda sigue siendo el estándar. El patrón recomendado es usar uv para paquetes de Python y conda (o PIXI) para dependencias a nivel de sistema. Muchos equipos científicos emparejan las dos herramientas: conda para la pila del sistema, uv para la capa de Python.

Si su proyecto involucra dependencias que no son de Python como MPI, CUDA o HDF5, consulte la guía relacionada sobre Administración de dependencias en Python científico, que cubre la conda, los archivos de bloqueo y cuándo usar cada herramienta.

Ruff: el linter que reemplaza a seis herramientas

Ruff es un linter y formateador basados en óxido construido por Astral. Reemplaza a Black (Formateando), iSort (Import ordenar), Flake8 (comprobaciones de estilo), PyUpgrade (eliminación de código muerto) y Autoflake (eliminación de variables no utilizadas) en un solo binario que se ejecuta de 10 a 100 veces más rápido que la pila anterior combinada.

Eso lo hace especialmente atractivo para la informática científica, donde las grandes bases de código con versiones mixtas de Python y módulos heredados pueden tardar varios segundos en verse con las herramientas tradicionales. Ruff lo hace en milisegundos.

Las bibliotecas científicas ya usan Ruff

Ruff ya no es solo un linter de marco web. Las principales bibliotecas científicas lo han adoptado:

• scipy — El equipo central de la biblioteca de métodos numéricos migró a Ruff.
• Pandas: utiliza Ruff para la aplicación del estilo en toda la base de código.
• Fastapi y cara de abrazo: ambos usan Ruff como su único formateador y linter.

Esta adopción es importante porque señala que Ruff maneja los casos extremos de código científico (cadenas de documentación largas, anotaciones de tipo complejo, importaciones heredadas de estilo Python-2) sin perder la corrección ni introducir errores de formato. La documentación oficial de Ruff enumera las tres bibliotecas como adoptantes. Consulte los documentos oficiales de Ruff para obtener la lista completa.

Configuración

Ruff se configura completamente desde pyproject.toml:

[tool.ruff]
line-length = 88
target-version = "py311"

[tool.ruff.lint]
select = ["E", "F", "I", "N", "W", "UP", "RUF"]
ignore = ["E501"]

[tool.ruff.format]
quote-style = "double"

La matriz select especifica qué conjuntos de reglas habilitar. E y F cubren los errores de PEP 8 y las comprobaciones de los copos de Py. I Maneja la clasificación de importaciones (reemplazando isort). N Hace cumplir las convenciones de nomenclatura. UP Ejecuta la modernización del estilo PyUpgrade. RUF Agrega reglas específicas de Ruff. La línea ignore elimina E501 (línea demasiado larga) porque Ruff delega la longitud de la línea al formateador, manteniendo el linter rápido.

Migración desde negro + iSort + Flake8

Eliminar la pila antigua es sencillo. Después de instalar Ruff, puede reemplazar los comandos:

# OLD stack
black .
isort .
flake8 .
pyupgrade --py38 src/

# NEW stack
ruff check .
ruff format .

ruff check Maneja todas las comprobaciones de estilo. ruff format Maneja todo el formato. Son dos comandos en lugar de cuatro, ejecutando un binario en lugar de cuatro separados.

La Guía de Desarrollo Científico de Python recomienda explícitamente migrar de Flake8 a Ruff para verificaciones de estilo. Consulte su guía de seguridad y desarrollo para conocer la recomendación oficial.

TY: Comprobación de tipo sin dolor

ty es el verificador de tipo de próxima generación de Astral, lanzado en diciembre de 2025. Reemplaza a myPy como el verificador de tipo estático recomendado en el ecosistema astral. Está escrito en óxido y diseñado para ser rápido, estricto por defecto y compatible con código no anotado.

La victoria de la velocidad

La ventaja más dramática de Ty es la velocidad. En un punto de referencia del mundo real de un usuario que migró de mypy a ty en una base de código de Python científico real, mypy tomó 46 segundos y Ty completó el mismo cheque en 2.19 segundos, aproximadamente 20 veces más rápido. Consulte el punto de referencia completo en La publicación de migración de StackAdemic.

Esto importa porque la verificación de tipos suele ser el paso de CI más largo en un flujo de trabajo de Python. Reducir 46 segundos a 2,2 segundos reduce los tiempos de cola de CI, permite a los desarrolladores obtener comentarios más rápidos y hace que la verificación de tipo completa sea factible en las ramas, donde incluso se habrían omitido los verificadores de tipo lento.

La garantía gradual

A diferencia de mypy, Ty implementa una garantía gradual: no aparecerá errores en el código que no tiene anotaciones. Si un módulo contiene def calculate(x, y): return x + y sin sugerencias de tipo, Ty lo trata como no escrito y no se queja de que faltan anotaciones. Esto es ideal para migrar bases de códigos científicos que tienen módulos parcialmente tipificados, un patrón común en el código de investigación donde se escribe el motor de simulación central, pero los scripts y cuadernos auxiliares no lo son.

el manual oficial de TY explica la garantía gradual en detalle. El punto clave es que agregar anotaciones de tipo a un módulo no hace que TY informe errores en ese módulo; solo informa errores en el código ya escrito. MyPy hace lo contrario: informa errores en cualquier función no anotada que encuentra, lo que rompe las bases de código existentes que carecen de anotaciones completas.

Conformidad de especificaciones: la compensación

Aquí está la compensación que debe comprender antes de poner ty en CI.

De acuerdo con una comparación completa de mypy, Pyright, Ty y Pyre, la conformidad de especificaciones de tipo Python de Ty se encuentra en aproximadamente 53 por ciento, mientras que Pyright logra aproximadamente 98 por ciento y mypy alcanza aproximadamente 58 por ciento. Esto significa que TY cubre solo la mitad de las características de las especificaciones de escritura, y puede pasar por alto los casos de Pyright que detecta.

Hasta que TY llegue a la versión 1.0, la estrategia de CI recomendada es un enfoque de dos capas:

1. Desarrollo local: use ty para comentarios rápidos (verificaciones de 2 segundos).
2. Tipelines de CI: use Pyright para una cobertura de especificaciones completa (capta los errores).

Esto le da velocidad y corrección. Una vez que Ty llega a 1.0 y su conformidad de especificaciones mejora, puede confiar solo en Ty para CI.

Configuración

ty configura desde pyproject.toml:

[tool.typer]
python-version = "3.11"
strict = true

El indicador strict habilita todas las comprobaciones de modo estricto (columna implícita, no-def sin tipo, etc.). Consulte El manual de TY para obtener la referencia de configuración completa.

Guía de migración: de pila antigua a nueva

Aquí está la comparación práctica de antes y después. Si actualmente está utilizando pip, venv, negro, isort, flake8 y mypy, esta tabla muestra exactamente qué reemplaza a cada herramienta.

Migración paso a paso

Aquí está la ruta de migración concreta para un proyecto existente:

# 1. Install uv and Ruff
uv pip install uv ruff

# 2. Create pyproject.toml (replacing setup.cfg)
cat >> pyproject.toml <<EOF
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.backends._deprecated"

[project]
name = "my-simulation"
version = "0.1.0"
dependencies = [
    "numpy",
    "scipy",
    "fipy",
]
EOF

# 3. Add Ruff config
cat >> pyproject.toml <<EOF

[tool.ruff]
line-length = 88
target-version = "py311"

[tool.ruff.lint]
select = ["E", "F", "I", "N", "W", "UP"]
ignore = ["E501"]
EOF

# 4. Add ty config
cat >> pyproject.toml <<EOF

[tool.typer]
python-version = "3.11"
strict = true
EOF

# 5. Run uv sync to manage dependencies
uv sync

# 6. Run Ruff to check and format existing code
ruff check .
ruff format .

# 7. Run ty locally for fast type feedback
ty check .

Esta ruta funciona porque la salida de Ruff es casi idéntica al estilo de formato de Black, por lo que el código formateado parece familiar. La garantía gradual de TY significa que no romperá los módulos no anotados durante la migración. Puede agregar anotaciones de tipo de forma incremental sin temor a que Ty supere los errores en el código que aún no ha escrito.

Si su proyecto se basa en requirements.txt, tenga en cuenta que uv puede instalar desde uv pip install -r requirements.txt. Pero para la reproducibilidad a largo plazo, genere un archivo uv.lock y aleje de requirements.txt. Consulte la guía relacionada sobre Gestión de dependencias en Scientific Python para obtener más información sobre archivos de bloqueo y reproducibilidad.

Lo que recomendamos: Un marco de decisión

No todos los equipos deben adoptar las tres herramientas simultáneamente. La pila correcta depende de los requisitos de su proyecto. Utilice este marco de decisión para elegir:

1. ¿Necesita dependencias que no sean de Python? (MPI, CUDA, HDF5, C++ Bibliotecas, compiladores Fortran)
   • Sí: use conda para esas dependencias. Todavía puede usar uv para los paquetes de Python junto con Conda.
   • No: Continúe con la siguiente pregunta.
2. ¿Estás publicando un paquete de Python en PYPI?
   • sí: Considere poesía para maduro Publicación de flujos de trabajo, o uv para instalaciones más rápidas durante el desarrollo. Ambos soportan la publicación PYPI.
   • no: uv es la opción predeterminada Proyectos.
3. ¿Estás trabajando en canalizaciones CI/CD donde importa el tiempo de instalación?
   • Sí uv. Las ganancias de velocidad (10-100× sobre PIP) reducen directamente los tiempos de cola de CI.
   • No: uv o la poesía puede funcionar dependiendo de la familiaridad del equipo.
4. ¿Qué tan importante es la cobertura de especificaciones de verificación de tipo completa en CI?
   • High: use pyright para CI, ty para el desarrollo local. Esto te da velocidad y corrección.
   • bajo: Ty solo es suficiente para la mayoría de las bases de código de investigación.

Para la mayoría de los nuevos proyectos de investigación, la pila recomendada es:

• UV para la gestión de paquetes y los archivos de bloqueo
• ruff para pelusas y formatear
• ty para la verificación de tipo local (comentarios rápidos)
• Pyright para la verificación de tipo CI (cobertura completa de especificaciones)

Esa combinación le da velocidad, corrección y reproducibilidad: los tres pilares de la calidad del software de investigación.

Limitaciones: Cuándo quedarse con las herramientas antiguas

La pila moderna es poderosa, pero no es un reemplazo universal. Aquí es cuando debes mantener las herramientas antiguas:

Conda para dependencias que no son de Python

UV administra paquetes de Python e intérpretes de Python. No maneja bibliotecas C compiladas, compiladores Fortran, MPI, CUDA Toolkits, HDF5, FFTW o bibliotecas de gráficos. Para ellos, CONDA (o PIXI) sigue siendo el estándar de la computación científica. Muchos equipos usan conda para las dependencias del sistema y uv para los paquetes de Python en el mismo entorno.

mypy para una cobertura de especificaciones completa

Hasta que TY alcance la versión 1.0 y cierre su brecha de conformidad de especificaciones, mypy o pyright es la opción más segura para entornos CI que necesitan una cobertura de verificación de tipo completa. Use ty para el desarrollo local donde la velocidad importa y el pyright (o mypy) para CI donde la corrección importa.

Poesía para Pypi

Si publica paquetes científicos de Python en PYPI, la poesía todavía tiene flujos de trabajo de publicación maduros, grupos de dependencias y una canalización de compilación bien documentada. uv Admite la publicación PYPI, pero sus flujos de trabajo son más nuevos y menos documentados que los de la poesía. Si su equipo valora la documentación establecida y los largos registros de producción, la poesía aún puede ser la mejor opción para el lado de la publicación de su flujo de trabajo.

Resumen y próximos pasos

La cadena de herramientas científica Python ha madurado. La pila de óxido (UV, Ruff y Ty) reemplaza las viejas herramientas fragmentadas con algo más rápido, simple y mejor integrado. Aquí están las comidas para llevar:

1. UV es el administrador de paquetes predeterminado para nuevos proyectos. Utilice --compile-bytecode en servidores y canalizaciones de CI. Use conda junto con ella para dependencias que no son de Python.
2. ruff reemplaza negro, isort, flake8, pyupgrade y autoflake. Scipy y Pandas ya lo usan. Configure todo desde pyproject.toml.
3. ty es el verificador de tipo más rápido disponible: 20× más rápido que mypy. Úselo localmente. Use Pyright para CI hasta que Ty llegue a 1.0.
4. PyProject.Toml es la única fuente de configuración. Las tres herramientas leídas de él. No más archivos de configuración dispersos.

Si está iniciando un nuevo proyecto de simulación, adopte la pila moderna desde el primer día. Si está migrando un proyecto existente, siga la ruta paso a paso anterior: la salida de formato de Ruff es casi idéntica a la de Black, y la garantía gradual de Ty significa que no romperá el código existente durante la transición.

Para un contexto más amplio en la pila de la biblioteca científica Python que se encuentra encima de esta herramienta, consulte la Guía del ecosistema de Python científico, que cubre Numpy, Scipy, Sympy, Matplotlib, Jupyter y Scikit-aprender. Para obtener una cobertura más profunda de la gestión de dependencias y los archivos de bloqueo, consulte la guía Gestionar dependencias en Scientific Python. Y para las mejores prácticas de mantenimiento que combinan bien con la cadena de herramientas moderna, lea la guía Mejores prácticas para mantener el código científico.

El ecosistema científico de Python no va a ninguna parte. Pero la forma en que trabaja con él ha cambiado, y la adopción de la pila moderna le brinda compilaciones más rápidas, una configuración más simple y una mejor reproducibilidad, todo sin cambiar las bibliotecas que usa para el cálculo.

Referencias y lectura adicional

• Documentación de Ruff — Guía oficial del linter y formateador basados en óxido.
• Repositorio de UV GitHub — Código fuente oficial y documentación de funciones.
• Embalaje Python en 2025: Presentamos UV — La descripción técnica de Franziska Hinkelmann sobre el diseño y la filosofía de UV.
• Administrador de paquetes Python UV: Peculiaridades y Lecciones aprendidas — La experiencia de adopción del mundo real de Plotly con UV.
• Configuración del proyecto Python 2026: UV, Ruff, Ty, Polars — Guía de configuración paso a paso para la pila moderna.
• Manual TY — Manual oficial que cubre las capacidades de TY, la garantía gradual y la integración de códigos VS.
• comprobados de tipo python — completo Comparación de MyPy, Pyright, Ty y Pyre con datos de conformidad de especificaciones.
• Cambié de mypy a ty (46s → 2.19s) — Benchmark de verificación de tipo en el mundo real en un código de base de código científico de Python.
• Guía de desarrollo de Python científico — Recomendaciones oficiales de la comunidad para Ruff y Ty.