Escribir y hacer linting de Python a escala
El trabajo de Meta en Fixit 2, un linter de Python con auto-corrección construido sobre libcst, impulsa una mirada más amplia sobre cómo hacer que Python funcione a gran escala mediante herramientas más sólidas, anotaciones de tipos y transformación automatizada de código. Los comentaristas contrastan el creciente ecosistema de tipado estático y linters de Python (incluidos Ruff y Fixit) con lenguajes como TypeScript y C#, debatiendo si los lenguajes dinámicos son bases adecuadas para sistemas grandes o simplemente están sostenidos por herramientas “parche”. Otros se centran en los compromisos prácticos: la facilidad de depuración y el rápido desarrollo en Python frente a sus límites de rendimiento, los problemas de threading y la calidad desigual de los hints de tipos y las bibliotecas en bases de código reales.
Contexto y herramientas discutidas
- El hilo se centra en el linter de Python Fixit 2 de Meta, construido sobre libcst, y en experiencias más amplias con linting y tipado de Python a escala.
- La característica notable de Fixit 2: reglas de lint que pueden aplicar cambios de código automáticamente, no solo informar de problemas.
Confianza y flujo de trabajo para linters con auto-corrección
- Algunos desconfían de los linters que cambian el código automáticamente más allá del formateo/imports.
- Otros señalan ecosistemas como C#/.NET, ESLint y Rubocop, donde el auto-fix es estándar y productivo, especialmente cuando:
- Las correcciones se aplican después del commit o mediante revisión de código con aceptación explícita.
- Solo se autoaplican categorías de correcciones “seguras”.
- Flujo de trabajo sugerido: hacer commit primero, ejecutar auto-fix y luego revisar el diff.
Ruff vs Flake8 y otros linters
- Se elogia Ruff por:
- Velocidad muy alta.
- Consolidar formateo, linting y ordenación de imports en una sola herramienta.
- Detectar problemas que algunos plugins de flake8 pasan por alto.
- Críticas:
- Inconsistencia con los plugins originales de flake8 en bases de código heredadas grandes y desordenadas.
- Algunas auto-correcciones introducían previamente nuevos problemas; las versiones más recientes de Ruff distinguen correcciones “seguras” de “inseguras”.
- Los mantenedores de Ruff (en el hilo) dicen:
- Su objetivo es lograr una corrección igual o mejor que la de los plugins y agradecen los informes de errores.
- El lint/fix es iterativo hasta que no queden más problemas corregibles.
- Varios comentaristas informan de una adopción exitosa de Ruff en muchos proyectos con pocos problemas.
Python a escala: tipado dinámico vs estático
- Hay un fuerte desacuerdo sobre si Python (y lenguajes de “scripting dinámico” similares) son adecuados para sistemas grandes:
- Críticos: las grandes empresas terminan recreando el tipado estático y herramientas pesadas; hoy los lenguajes estáticos ya prototipan lo bastante rápido, así que empezar con lenguajes dinámicos es un error.
- Defensores: el sistema de tipos opcional de Python, los tipos suma, el pattern matching y los verificadores externos lo hacen viable y cada vez más “seguro”.
- Un largo subhilo debate la terminología (“lenguaje dinámico”, “tipado dinámico”) y detalles de teoría de tipos: tipos recursivos (JSON), generics variádicos, concatenación de tuplas y comparación con TypeScript y Haskell.
Fortalezas y debilidades de Python
- Los partidarios destacan:
- Facilidad de depuración y errores de ejecución claros.
- Buena sintaxis y adecuación para la enseñanza.
- Las anotaciones de tipos mejoran la escalabilidad de bases de código grandes.
- Los críticos sostienen:
- Python nunca es la “mejor” herramienta por méritos de ingeniería; dominan la popularidad y las herramientas parche.
- El rendimiento y el threading (GIL) siguen siendo límites reales de escala; las soluciones suelen implicar subprocesos.
Deseo de herramientas unificadas
- Algunos quieren una sola herramienta que maneje formateo, linting, ordenación y comprobaciones de pre-commit, preocupándose más por la coherencia que por los detalles del estilo.
- Ruff se ve como un candidato prometedor; su financiación se considera un posible acelerador hacia una coherencia de “una sola herramienta”, incluyendo posiblemente reemplazar el ecosistema fragmentado actual de pre-commit.