Viene del grupo de Telegram, al hilo de la pregunta recurrente en todas las entrevistas a los core developers «¿cuál es el futuro del lenguaje?», mi respuesta fue:
yo creo que más allá del “puterío” y del “hate”, estaría bien evaluar cómo se sienten los usuarios frente a los cambios del lenguaje. no solo tenemos releases más recientes, sino que cada release introduce cambios muy grandes de sintaxis, algunos con muchos corner cases y cosas sorprendentes (walrus, pattern matching). se presenta un PEP que depende de otro PEP sin que el primero se haya aprobado (PEP 646, que dependía del 637, y que no se aprobó), se presentan PEPs con supuestos beneficios a la comundidad sin hablar con la comunidad (PEP 637 que ofrecía “mejoras para xarray y pandas” y parece que no se habló con los devs de xarray y pandas)… etcétera, etcétera.
a mí estas cosas me dan igual, yo voy a seguir enseñando un subconjunto de Python muy pequeño a mis alumnos (nada de typing, annotations, asyncio, protocols, walrus, pattern matching, descriptores, metaclases), y así voy a seguir. el resto lo pueden aprender por su cuenta. pero usar a los energúmenos (que los hay, como ya mostró Pablo) como hombre de paja para decir que no existen críticas fundadas y dudas razonables me parece un error.
Yo creo que en general las políticas de implementación y deprecation de nuevas features son bastante sensatas. Actualmente el ciclo de vida de una branch incluye un año de alpha/RC releases y cinco años hasta el EOL. Pero es una opinión personal basada en mi experiencia y por supuesto que existen motivos de sobra para cuestionarlas.
Comparto contigo que en ocasiones es confuso seguir la evolución de ciertas PEPs, como en el caso que comentas, aunque creo que es positivo que se puedan presentar PEPs dependientes de otras abiertas para completar algunas que estén en proceso de evaluación o para no lastrar el desarrollo de nuevas features. Lo que quizás sí podría ser beneficioso para la comunidad sería establecer un estadio previo al de PEP para distinguir claramente las que ya han sido aceptadas o provisionalmente aceptadas de las que no, algo como un Python Enhancement Draft. Habitualmente el interés sobre una PEP no aprobada implica a un número significativamente reducido de desarrolladores… salvo honrosas y polémicas excepciones como la del operador walrus
Respecto al subconjunto que comentas, quizás las partes de metaprogramación y tipado estático y estructural correspondan ya a un nivel avanzado. Pero personalmente opino que asyncio debería enseñarse lo antes posible. No tanto por el módulo en sí, que tuvo un desarrollo un tanto accidentado y a mi juicio innecesariamente complejo (algo como trio habría evitado muchos de los problemas que afectaron a asyncio) sino porque es la implementación estándar para escribir código concurrente empleando async/await y eso representa un cambio de paradigma nada trivial que hay que trabajar a fondo para ayudar a visualizar el flujo de ejecución y entender todas las posibilidades (y enormes ventajas) que representa.
El caso de PEP582 sí que es bastante curioso, porque a pesar de que parece que se ha detenido en algún punto de la evaluación, hay un número creciente de herramientas que la están implementando e incluso hay ya varios package managers basados en ella (pyflow, pdm, pythonloc, …). Creo que ésta será la primera PEP que se apruebe por aclamación popular. Y yo estoy a favor de ello, pero tengo que reconocer que he escuchado uno de los argumentos en contra más demoledores que recuerde: friends don’t let friends reimplement node_modules
Un saludo!
PD: ¿Habéis tratado por aquí alguna vez el tema “una PEP” vs “un PEP”? Empiezo a sospechar que es más frecuente el uso de “un”
