Hola Habr! Le presento la traducción de
Hacia un artículo sobre "Kernel Python" de Glyph Lefkowitz (creador del marco Twisted).
Más detalles - debajo del corte.
La magia de minimizar la biblioteca estándar.
Bajo la influencia
del discurso de Amber Brown el mes pasado en la Cumbre del lenguaje de Python (lo que significa que su informe de mayo "Las baterías están encendidas, pero están goteando" - comentario del traductor), Christian Hymes continuó
su trabajo para reducir la biblioteca estándar de Python y creó una propuesta
PEP 594 para la eliminación explícita fragmentos obsoletos y sin soporte de la misma.
El advenimiento de PEP 594 ("Eliminación de baterías muertas de la biblioteca estándar") es una gran noticia para los pitonistas, especialmente aquellos que apoyan la biblioteca estándar y ahora tendrán un frente de trabajo más pequeño. Un breve recorrido por la galería PEP de módulos obsoletos o de eliminación habla por sí mismo (los módulos sunau, xdrlib y chunk son mis favoritos personales). La biblioteca estándar de Python contiene muchos módulos útiles, sin embargo, también incluye una necrópolis de código real, un monumento imponente de fragmentos obsoletos que amenazan con enterrar a sus desarrolladores en cualquier momento.
Sin embargo, creo que el enfoque erróneo puede implementarse en esta oración PEP. La biblioteca estándar es actualmente compatible con los desarrolladores de CPython. Grandes piezas quedaron con la vaga esperanza de que algún día beneficiaría a alguien. En el PEP mencionado anteriormente, este principio se puede observar al proteger el módulo colourysys. ¿Por qué no eliminarlo? Respuesta: “Este módulo es necesario para convertir colores CSS entre sistemas de coordenadas (RGB, YIQ, HSL y HSV). [Él] no impone costos adicionales en el desarrollo central ”.
Hubo momentos en que el acceso a Internet era limitado, y podría haber sido una buena idea precargar Python con una tonelada de material, pero hoy en día los módulos necesarios para convertir colores entre diferentes sistemas de coordenadas están a un paso del comando de instalación de pip.
¿Por qué no consideró mi solicitud de piscina?
Entonces, echemos un vistazo a esta declaración: ¿los módulos pequeños como colorsys imponen un "costo adicional en el desarrollo central"?
Es suficiente para los principales desarrolladores que estén tratando de mantener una base enorme y antigua de código C, que es el propio CPython. Como dijo Marietta Viggia en
su discurso en North Bay Python, la pregunta más común que hacen los desarrolladores del kernel es: "¿Por qué no han mirado la solicitud de mi grupo?" Y cual es la respuesta?
Es más fácil ignorar estas solicitudes de grupo. ¡Eso es lo que significa ser un desarrollador de kernel!
Uno podría preguntarse, ¿Twisted tiene el mismo problema? Twisted también es una gran colección de módulos sueltos; una especie de biblioteca estándar para redes. ¿Son todos estos clientes y servidores para SSH, IMAP, HTTP, TLS, etc. etc. tratando de exprimir todo en un paquete?
Obligado a responder:
sí . Twisted es monolítico porque proviene del mismo período histórico que CPython, cuando la instalación de componentes fue realmente complicada. Por lo tanto, simpatizo con la posición de CPython.
Idealmente, en algún momento, cada subproyecto en Twisted debería convertirse en un proyecto separado con su propio repositorio, integración continua (CI), sitio web y, por supuesto, con sus propios desarrolladores más enfocados. Ya estamos compartiendo lenta pero seguramente proyectos donde se puede trazar un límite natural. Algunos de los puntos que comenzaron en Twisted como constante e incremental están separados, diferidos y filepath están en proceso de separación. Otros proyectos, como klein y treq, continúan viviendo por separado. Haremos más cuando descubramos cómo reducir los costos de configuración y soporte de la integración continua y cómo liberar la infraestructura para cada uno de ellos.
Pero, ¿es la naturaleza monolítica de Twisted el problema más urgente o incluso grave para el proyecto? Vamos a apreciarlo
En el momento de escribir esto, Twisted tenía 5 solicitudes de grupo pendientes sin resolver en línea. El tiempo promedio que se pasa considerando un boleto es, aproximadamente, cuatro días y medio. El boleto más antiguo en la cola está fechado el 22 de abril, lo que significa que han pasado menos de 2 meses desde que se envió la solicitud de grupo no revisada más antigua.
Siempre es difícil encontrar suficientes desarrolladores y tiempo para responder a las solicitudes del grupo. A veces parece que todavía recibimos la pregunta "¿Por qué no estás considerando mi solicitud de grupo?" No siempre lo hacemos a la perfección, pero en general lo logramos; la cola fluctúa entre 0 y 25 más o menos en el mes más desafortunado.
¿Qué pasa con el núcleo de CPython en comparación con estos números?
Después de
visitar el github , puede ver que 429 boletos están esperando su consideración en este momento. El más antiguo de ellos se espera para el 2 de febrero de 2018, es decir, casi 500 días.
¿Cuántos problemas con el intérprete y cuántos problemas con la biblioteca stdlib? Obviamente, una revisión pendiente es un problema, pero ¿ayudará la eliminación de stdlib?
Para una evaluación rápida y poco científica, miré la primera página (más antigua) de solicitudes de grupo. En mi evaluación subjetiva, de 25 solicitudes de grupo, 14 estaban asociadas con la biblioteca estándar, 10 con el núcleo del idioma o el código del intérprete, y una estaba asociada con un pequeño problema de documentación. Sobre la base de esta proporción, me aventuraría a sugerir que en algún lugar alrededor de la mitad de las solicitudes de grupo no revisadas están asociadas con el código de biblioteca estándar.
Entonces, la primera razón por la cual el equipo principal de CPython necesita dejar de admitir la biblioteca estándar es porque
literalmente no tienen la capacidad física para admitir la biblioteca estándar. O, en otras palabras,
no lo respaldan , y solo queda admitirlo y comenzar a compartir el trabajo.
Es un hecho que ninguna de las solicitudes de pool abierto de CPython está asociada con el módulo colorsys. De hecho, no impone costos en el desarrollo del núcleo.
El desarrollo del núcleo en sí mismo impone estos costos. Si quisiera actualizar el módulo colorsys para estar al día (tal vez para tener un objeto Color, tal vez para admitir modelos de color enteros), lo más probable es que tenga que esperar 500 días o más.
Como resultado de todo esto, es más difícil cambiar el código en la biblioteca estándar, lo que genera un menor interés de los usuarios en contribuir. Las versiones poco frecuentes de CPython también ralentizan el desarrollo de la biblioteca y reducen los beneficios de los comentarios de los usuarios. No es coincidencia que casi todos los módulos de la biblioteca estándar hayan admitido activamente alternativas de terceros, y esto no es culpa de los desarrolladores de stdlib. Todo el proceso se agudiza para estancar todos los módulos stdlib que se usan con más frecuencia.
Nuevos entornos, nuevos requisitos.
Quizás aún más importante es que vincular CPython a la biblioteca estándar coloca a CPython en una posición privilegiada en comparación con otras implementaciones de lenguaje.
El podcast después del
podcast , el
podcast después del
informe, nos dice que para continuar con éxito y desarrollar Python, debe crecer en nuevas áreas: especialmente en el front-end, así como en clientes móviles, sistemas integrados y juegos de consola.
Estos entornos requieren una o dos condiciones:
- un tiempo de ejecución completamente diferente (ver Brython o MicroPython )
- versión reducida y modificada de la biblioteca estándar.
En todos estos casos, el escollo es la definición de módulos que deben eliminarse de la biblioteca estándar. Necesitan ser encontrados por prueba y error; En primer lugar, el proceso es completamente
diferente del proceso de determinación de dependencia estándar en una aplicación Python. No hay una declaración install_requires en setup.py que informa que la biblioteca usa un módulo de stdlib que el tiempo de ejecución de Python de destino podría omitir debido a limitaciones de espacio.
Un problema puede ocurrir incluso si todo lo que usamos es Python estándar en una instalación de Linux. Incluso las distribuciones de Linux para servidores y computadoras de escritorio tienen la misma necesidad de un paquete de kernel Python más pequeño, por lo que la biblioteca estándar ya está bastante truncada en ellos. Es posible que esto no cumpla con los requisitos del código Python y, como resultado, genere errores cuando incluso la
instalación de pip no funcionará .
Llévatelo todo
“¿Qué pasa con la suposición de que necesitas limpiar un poco todos los días? Aunque parezca convincente, no te dejes engañar. La razón por la que te parece que la limpieza nunca termina es precisamente porque estás limpiando un poco. [...] El secreto principal del éxito es este: si lo quitas de un solo golpe, y no gradualmente, entonces puedes cambiar permanentemente tus pensamientos y hábitos de vida "
Marie Kondo, Limpieza Mágica. El arte japonés de restaurar el orden en el hogar y en la vida "(p. 15-16)
Si bien la reducción gradual de la biblioteca estándar es un paso en la dirección correcta, los cambios graduales por sí solos no son suficientes. Como dice Marie Kondo, si realmente quieres poner las cosas en orden, el primer paso es
sacar todo de la vista para poder verlo todo y luego devolver solo lo que se necesita.
Ha llegado el momento de rendir homenaje a esos módulos que ya no son alentadores, y enviarlos un largo camino.
Necesitamos una versión de Python que contenga solo el mínimo más necesario para que todas las implementaciones puedan ser consistentes, y para que las aplicaciones (incluso las que funcionan en navegadores web o microcontroladores) puedan simplemente indicar sus requisitos en require.txt.
En algunos entornos empresariales, la idea de una gran biblioteca estándar parece atractiva porque la adición de dependencias en requisitos.txt es burocrática, sin embargo, la "biblioteca estándar" en dichos entornos tiene límites puramente arbitrarios.
Todavía podría ser una buena idea suministrar algunas de las distribuciones binarias de CPython (posiblemente incluso las oficiales) con una amplia selección de módulos de PyPI. De hecho, incluso para tareas ordinarias, se requiere una cierta cantidad de la biblioteca stdlib, que pip necesita para instalar otros módulos necesarios.
Ahora hay una situación en la que pip se distribuye junto con Python, pero
no se desarrolla en el repositorio de CPython. Parte de lo que viene con el instalador predeterminado de Python se desarrolla en el repositorio de CPython, parte viene en un tarball separado para el intérprete.
Para usar Linux, necesitamos medios de arranque con una gran variedad de programas adicionales. Pero esto no significa que el kernel de Linux esté ubicado en un repositorio gigante, en el que un equipo desarrolle cientos de aplicaciones necesarias para un servidor Linux en funcionamiento. El kernel de Linux es extremadamente valioso, pero los sistemas operativos que lo utilizan se crean a partir de una
combinación del kernel de Linux y una amplia gama de bibliotecas y programas desarrollados por separado.
Conclusión
La filosofía de "baterías incluidas" era ideal para su creación; como un cohete de refuerzo, entregó Python al público de programación. Sin embargo, a medida que los ecosistemas de código abierto y los paquetes de Python maduran, esta estrategia se vuelve obsoleta y, como cualquier acelerador, debemos dejar que regrese al suelo para que no nos arrastre hacia atrás.
Los nuevos tiempos de ejecución de Python, las nuevas tareas de implementación y las nuevas audiencias de desarrolladores brindan a la comunidad de Python enormes oportunidades para alcanzar nuevas alturas.
Pero para lograr esto, necesitamos un núcleo Python nuevo, más compacto y no sobrecargado. Necesitamos sacudir toda la biblioteca estándar al piso, dejando solo las piezas más pequeñas que necesitamos para que podamos decir: esto es realmente necesario, pero es agradable tenerlo.
Espero haber convencido al menos a algunos de ustedes de qué núcleo de Python necesitamos.
Y ahora: ¿quién quiere escribir
PEP ?