¿Dónde estará Python dentro de 100 años? Es la pregunta que Lex Fridman, investigador de IA del MIT, planteó a Guido van Rossum, creador de Python, al final de una amplia entrevista de tres horas.
Es sólo una de las formas en las que exploraron cómo evoluciona un lenguaje de programación popular, junto con preguntas específicas sobre el propio futuro de Python. ¿Cómo mejorarán la biblioteca estándar de Python? ¿Llegará Python a tener un comprobador de tipos estático? ¿Qué perspectivas hay de mejorar el bloqueo global del intérprete de Python, que reduce el rendimiento? ¿Y qué medidas tomarían para evitar otro doloroso cambio de última hora como la transición a Python 3...?
Pero en el camino, Fridman también planteó a van Rossum una pregunta más hipotética sobre el papel del lenguaje Python en un futuro lejano dentro de un siglo. "¿Alguna vez ha imaginado un futuro en el que la civilización humana viva en el metaverso, en Marte, con humanos y robots por todas partes?. Aquí el detalle de la Entrevista.
"¿Qué papel juega Python en eso?"
Año 2122
Python existe desde hace más de 30 años, así que van Rossum ya ha visto el flujo y reflujo de los lenguajes de programación más populares. Así que, en respuesta a la pregunta de Fridman, van Rossum contestó que, si transcurren suficientes décadas, el inmensamente popular Python "acabará convirtiéndose en un lenguaje heredado, que desempeña un papel importante, pero del que la mayoría de la gente nunca ha oído hablar y que no necesita conocer". Aunque la gente pueda construir sobre él, Python quedaría enterrado en algún lugar más abajo, en este mundo hipotético con muchas capas de abstracciones - continuando nuestra progresión en curso. "Quiero decir, la mayoría de los programadores de hoy en día rara vez necesitan hacer aritmética binaria, ¿verdad?"
El meta-mensaje parece ser que van Rossum sigue confiando en el atractivo duradero del lenguaje - y aquí en el presente, van Rossum dice que no está observando activamente las lagunas que necesitan ser llenadas en la biblioteca estándar de Python. "Normalmente, cuando falta algo en la biblioteca estándar, se trata de una idea relativamente nueva y existe una implementación de terceros, o quizá varias. Pero evolucionan a un ritmo mucho mayor de lo que podrían hacerlo cuando están en la biblioteca estándar... Me gusta que haya un ecosistema de paquetes animado."
Ahora que ha abandonado su papel de "dictador benévolo vitalicio" -transfiriendo el control del lenguaje en 2019 a un Consejo Directivo de Python-, van Rossum sigue viendo una continuidad en la claridad de la visión de Python para el futuro. La ventaja de la antigua jerarquía era su previsibilidad - con Guido trazando "un camino claro y bastante recto".
"Afortunadamente, la estructura sucesora con el consejo directivo ha encontrado una forma similar de llevar a la comunidad en una dirección bastante estable sin estancarse".
"Y para mí, personalmente, es más divertido, ¡porque hay cosas que puedo simplemente ignorar! 'Oh, ¿hay un fallo en el multiprocesamiento? ¡Que otro decida si es importante resolverlo o no'! Me quedo con la mecanografía y el IO asíncrono y el intérprete más rápido".
Revisitando 1991
Van Rossum forma parte ahora de un equipo de Microsoft que trabaja para acelerar el rendimiento del lenguaje. En octubre,un blog de Microsoft informaba de que Python 3.11 había aumentado la velocidad entre un 10 y un 60% en algunas partes del lenguaje. Cuando se le preguntó cómo se había conseguido, van Rossum opinó que habían corregido decisiones de diseño que se remontaban a los orígenes de Python. En la búsqueda de formas de acelerar Python, la "fruta madura" era el intérprete, donde habían centrado casi todos sus esfuerzos.
¿Un ejemplo? Algo tan simple como un signo más tiene múltiples significados, con funciones "añadir" completamente diferentes dependiendo del tipo de datos que se añadan. ¿Era un número entero normal o un número de coma flotante (con dígitos adicionales después del punto decimal), o una cadena? ¿O una combinación de distintos tipos de datos? "Sabemos estadísticamente que el resultado es casi siempre sí, ambos son enteros", dice van Rossum, "así que hacemos rápidamente esa comprobación y luego procedemos con la operación Añadir entero".
"Y luego hay un mecanismo de emergencia en el que decimos: 'Uy, uno de ellos no era un entero....'".
Todo se reduce a algo fundamental sobre el lenguaje: que Python no requiere que sus programadores declaren el tipo de una variable. Esto facilita la vida a los programadores, pero introduce una falta de eficiencia rápida en el intérprete. "Así que intentamos que la interpretación sea más eficiente sin perder la naturaleza superdinámica del lenguaje. Ése es siempre el reto".
Pero ¿qué pasa con la posibilidad de un Python que en su lugar sólo ofreciera tipado estático - con tipos de variables declarados en el código, para acelerar el rendimiento. Fridman señaló a van Rossum mypy, el comprobador de tipos estáticos experimental (y opcional) de Python, y le preguntó: "¿Cuál es la situación actual de mypy y cuál es el futuro del tipado estático en Python?".
"Sigue siendo controvertido", dice van Rossum. "Pero es mucho más aceptado que cuando mypy y Python Enhance Proposal #484 eran jóvenes.... "Introducida en 2014, la PEP 484 inició "un año muy productivo en el que se intercambiaron muchos cientos de mensajes debatiendo los méritos de cada aspecto de eso..." (Fridman citó estimaciones de que hoy en día entre el 20 y el 30% de las bases de código de Python 3 ya están usando type hints).
Y van Rossum señaló que Google, Facebook y Microsoft han desarrollado desde entonces sus propios comprobadores de tipos estáticos para Python, lo que habla del interés que despierta. "Mi suposición es que muchas, muchas personas que desarrollan software Python profesionalmente, para algún tipo de situación de producción, están utilizando un verificador de tipo estático. Especialmente cualquiera que tenga un ciclo de integración continua - probablemente, uno de los pasos en su rutina de pruebas que sucede básicamente para cada commit es 'Ejecutar un verificador de tipo estático'.... Así que creo que es un tema bastante popular ".
Fridman se pregunta si habrá un futuro en el que un comprobador de tipos estático se integre en el lenguaje. "Nadie está actualmente entusiasmado con la idea de trabajar en ese sentido", responde van Rossum, antes de añadir: "Eso no significa que dentro de cinco o diez años la situación no sea diferente".
Pero también señala que, dado que las nuevas versiones de Python sólo se publican una vez al año, los comprobadores de tipos "evolucionan a una velocidad mucho mayor que Python y su sintaxis de anotaciones".
van Rossum también señala que una vez que se introduce una nueva característica en un lenguaje, hay que asumir que la gente la utiliza. Lo que significa que "una vez que todos nos hemos puesto de acuerdo en que vamos a introducir una nueva sintaxis, ya no podemos volver atrás". Al menos, dejar obsoleta una característica existente lleva muchas versiones...".
Más futuros posibles
La conversación giró en torno al infame Bloqueo Global del Intérprete de Python, que previene las "condiciones de carrera" permitiendo sólo un hilo en el intérprete a la vez. Por ello, a menudo se le culpa de ralentizar el rendimiento de Python. (Es una decisión de diseño que van Rossum atribuye a la época en que las CPU multinúcleo eran poco comunes).
A la pregunta de si hay ideas para eliminarlo de Python -quizás sustituirlo por múltiples subinterpretadores-, van Rossum responde: "Sí, hay un par de futuros posibles. El futuro más probable es que tengamos múltiples subinterpretadores, cada uno de los cuales ejecuta un programa Python completamente independiente, pero con la ventaja de una comunicación más rápida entre esos programas..."
Pero eso abre la posibilidad de que esos temidos bugs de concurrencia sorprendan a los programadores - lo que van Rossum llama "la perdición del modelo de programación multihilo."
Y aquí van Rossum reitera su postura de que "Los bugs de concurrencia son simplemente más difíciles... Estaría bien que Python no tuviera bloqueo global del intérprete, y que tuviera el llamado roscado libre - pero también causaría muchos más bugs de software."
Y sin embargo, "todavía hay un posible futuro en el que realmente vamos a, o donde podríamos experimentar al menos con eso". Señala el fork de Facebook de CPython con un intérprete mejorado que elimina el bloqueo por completo (junto con otras optimizaciones). "El caso de un solo hilo no es mucho más lento, y los casos de varios hilos utilizarán todos los núcleos que tengas. Sería una posibilidad interesante, si los desarrolladores del núcleo de Python estuviéramos dispuestos a mantener ese código indefinidamente. Y si estamos dispuestos a soportar la complejidad adicional del intérprete, y la sobrecarga adicional para el caso de un solo hilo".
Pero también podría no ocurrir. "Personalmente, no estoy convencido de que haya suficientes personas que necesiten la velocidad de múltiples hilos con sus programas Python como para que merezca la pena asumir ese golpe de rendimiento y ese golpe de complejidad. Y creo que el Bloqueo Global del Intérprete es un buen punto intermedio entre ningún hilo y todos los hilos todo el tiempo. Pero no todo el mundo está de acuerdo con eso, así que definitivamente es un futuro posible".
Y mientras tanto, "Los subintérpretes parecen una apuesta bastante segura para Python 3.12, digamos dentro de un año".
Cuando Python 2 se convirtió en Python 3
Al repasar la historia de Python, Fridman recordó la larga transición de Python a Python 3 (que no era retrocompatible con Python 2). Fridman preguntó si volvería a producirse una interrupción semejante, e inmediatamente van Rossum subrayó que, incluso hipotéticamente, "si va a haber una, planificaremos la transición de forma muy diferente, porque está claro que subestimamos el dolor que la transición causó a nuestros usuarios en el caso de Python 3. Y si lo hubiéramos sabido, habríamos podido planificar la transición de forma diferente. Y si lo hubiéramos sabido, podríamos haber diseñado Python 3 de forma algo diferente, sin empeorarlo. Pensábamos que teníamos un buen plan. Pero subestimamos hasta dónde - lo que los usuarios eran capaces de hacer cuando se trata de ese tipo de transición...."
"Si vamos a tener un Python 4, vamos a tener que tener tanto una razón diferente para tenerlo - ¡como un proceso diferente para gestionar la transición!"
Fuente: somoslibres
