El verdadero superpoder de Python
(youtu.be)Este es un resumen de la keynote de Hynek Schlawack, "El verdadero superpoder de Python", presentada en PYCON UK 2025.
Antes de comenzar la presentación, el ponente presentó brevemente su trayectoria y mencionó en particular la "amistad odiosa" que ha vivido durante 14 años participando en la comunidad de PyCon.
La transición de Python 2 a 3 (The Python 2 to 3 Migration)
- Contexto: Python 3.0 se lanzó por primera vez en 2008, y no estaba pensado para consumo general, sino para mostrar los objetivos de Python y recibir retroalimentación. Su uso comenzó a recomendarse a partir de Python 3.2.
- Cambios principales:
- Manejo de cadenas: Python 3 cambió el tipo de cadena predeterminado de bytes, orientado a la máquina, a Unicode, orientado a las personas.
- Eliminación de comportamientos implícitos: Se eliminaron muchos comportamientos implícitos en los que los desarrolladores dependían por error en Python 2, como comparar cadenas con números. Esto provocaba bugs difíciles de depurar.
- Mejora de la internacionalización: Las bases de código de Python 2 estaban llenas de errores de decodificación Unicode, y Python 3 mejoró esto para convertirlo en un lenguaje más internacionalizado.
- Dificultades de la transición:
- Costo para la comunidad: Portar todo el ecosistema a Python 3 tuvo un costo enorme. Había mucho software que migrar, y en ese momento la cobertura de pruebas no era algo generalizado.
- Desarrollo de bases de código mixtas: No hubo consenso sobre cómo escribir bases de código híbridas que corrieran tanto en Python 2 como en Python 3 hasta 2012, cuando se lanzó Python 3.3.
- Moratoria del lenguaje: Entre Python 3.0 y 3.3 casi no se agregaron funciones nuevas, así que los desarrolladores tenían pocos incentivos para migrar a Python 3.
- Incertidumbre: No estaba claro si Python 3 llegaría a convertirse en la versión dominante, y existía la posibilidad de que fracasara, como ocurrió en casos como Perl 6.
- Por qué Python sobrevivió:
- Entrada de nuevos usuarios: Python seguía incorporando más usuarios nuevos de los que perdía, mientras crecían otros lenguajes como Go y Rust.
- Comunidad científica y de ingeniería: Científicos e ingenieros han usado Python desde hace mucho tiempo, y desde mediados de la década de 2010 su popularidad explotó en ciencia de datos. Hoy, más de la mitad de los usuarios de Python lo usan para exploración y procesamiento de datos.
- Ecosistema existente: Ya existía un ecosistema sólido de bibliotecas de cómputo científico, como NumPy.
- Facilidad para interactuar con otros lenguajes compilados: Python interactúa fácilmente con otros lenguajes compilados, por lo que puede funcionar como un "pegamento" que conecta componentes de alto rendimiento escritos en C, C++, Fortran o Rust.
- Programación exploratoria: Python es muy adecuado para la programación exploratoria gracias a herramientas como el shell interactivo (REPL) y Jupyter Notebook.
- Gradualidad: Python ofrece distintos niveles de rigor. Los desarrolladores pueden trabajar con flexibilidad durante la etapa experimental y aumentar la rigurosidad en producción usando herramientas como type hints, linters y pruebas. También permite aplicarse a distintos casos de uso, como empezar en Jupyter Notebook y escalar luego a un servicio web.
El verdadero superpoder de Python: la gradualidad (Graduality)
- Python no solo tiene una barrera de entrada baja, sino que también ofrece varios techos altos que permiten a cada usuario aprovecharlo con flexibilidad según sus necesidades.
- Las dos caras de la gradualidad:
- Lado positivo: Los usuarios pueden elegir el nivel de rigor y complejidad que desean. Por ejemplo, al escribir scripts pueden programar libremente sin type hints, mientras que en aplicaciones grandes pueden aplicar verificación estricta de tipos.
- Lado negativo: Cuando se agregan casos especiales o excepciones al sistema, eso puede dar comodidad a ciertos usuarios en el corto plazo, pero a largo plazo aumenta la complejidad general del sistema. Se enfatiza que "lo fácil no siempre es simple", y esto se refleja en la forma en que Python maneja el packaging.
Ejemplo del problema de packaging (Packaging Problem Example)
- Hay dos formas de estructurar una aplicación en Python: la forma "ad hoc" y la forma de "paquete". La forma de paquete está mejor definida y tiene herramientas integradas, pero por razones históricas la forma ad hoc sigue siendo compatible.
- Esto dificulta entender problemas relacionados con
sys.path, y funciones comopip install --usergeneran problemas en el namespace global que vuelven más difícil la depuración. - Herramientas nuevas como UV al principio solo soportaban la forma de paquete, pero terminaron añadiendo soporte para proyectos ad hoc, lo que incrementó la complejidad.
- Estas "molestias seductoras" (
attractive nuisance) ofrecen conveniencia a corto plazo, pero a largo plazo generan costos considerables para la comunidad.
Arquitectura de software (Software Architecture)
- Señala que en la comunidad de Python falta discusión sobre arquitectura de software, y menciona que esto se debe a la aversión hacia los "patrones enterprise" y al "miedo a convertirse en Java".
- Necesidad: Para construir y mantener sistemas de software complejos, es importante discutir la arquitectura de software que organiza y gestiona módulos, capas e interacciones.
- Soluciones:
- La comunidad de Python debe evitar terminar las conversaciones usando términos como "pythonic" o "unpythonic".
- Debe aprender y aplicar mejores prácticas de comunidades de otros lenguajes, como el diseño guiado por el dominio.
- Más personas deberían compartir conocimiento relacionado con arquitectura de software, crear contenido sobre el tema y enfocarse en soluciones.
Conclusión (Conclusion)
- No hay que sentirse ansioso por Python; hay que aceptar las distintas formas de escribir Python.
- Hay que probar estilos y herramientas nuevas para ampliar la forma de pensar.
- Las opciones tienen un costo, así que hay que considerar con cuidado el impacto que ciertas funciones tienen sobre toda la comunidad.
- Junto con el trabajo de hacer simples las cosas sencillas, también hay que dedicar más esfuerzo a hacer posibles las cosas complejas.
- Hace falta hablar más sobre arquitectura de software y cuestionar las formas de pensar dogmáticas para llevar a Python hacia un futuro mejor.
Esta presentación recorre el pasado, presente y futuro de la comunidad de Python, enfatiza que la verdadera fortaleza del lenguaje es la "gradualidad" y ofrece una visión profunda sobre los retos que enfrenta la comunidad y las barreras culturales que debe superar.
Si quieres ver el video, consulta el siguiente enlace: https://youtu.be/gDvwRpl9erE
3 comentarios
Sería mucho más cómodo si un administrador de paquetes moderno al estilo de
uvse convirtiera en el estándar, pero supongo que de todos modos sería difícil...Recuerdo que, a inicios de la carrera,
python 2todavía era apenas más predominante, pero para cuando me gradué, todos ya se habían pasado apython 3.Si alguien se dedica profesionalmente a programar, incluso si usa principalmente Python, lo más probable es que maneje al menos otro lenguaje además de ese.
No entiendo eso de insistir en que Python tiene que mejorar e intentar introducir una y otra vez funciones o características de otros lenguajes.
Parece que se está ignorando que esas carencias de Python también son parte de la razón por la que se volvió popular.
Python se está volviendo cada vez más extrañamente complejo y quisquilloso.
Siento que se están perdiendo las ventajas de usar Python.
En vez de intentar convertir Python en Java, ¿no sería más simple usar Java cuando haga falta?
Y si no es Java, también están Kotlin y Scala.
Aun así, no creo que Python vaya a desaparecer.
Porque, en la práctica, no existe otro lenguaje con el que se pueda programar de una forma tan sencilla.