En route vers le noyau Python

Bonjour, Habr! Je vous présente la traduction de l'article Vers un «Kernel Python» de Glyph Lefkowitz (créateur du framework Twisted).

Plus de détails - sous la coupe.

La magie de minimiser la bibliothèque standard

Sous l'influence du discours d'Amber Brown le mois dernier au Python Language Summit (se référant à son rapport de mai «Les piles sont allumées, mais elles fuient» - commentaire du traducteur), Christian Hymes a poursuivi son travail pour réduire la bibliothèque Python standard et a créé une proposition PEP 594 pour une suppression explicite des fragments obsolètes et non pris en charge.

L'avènement du PEP 594 («Retrait des piles mortes de la bibliothèque standard») est une excellente nouvelle pour les pythonistes, en particulier ceux qui prennent en charge la bibliothèque standard et auront désormais un front de travail plus petit. Une brève visite de la galerie PEP de modules obsolètes ou basés sur la suppression parle de lui-même (les modules sunau, xdrlib et chunk sont mes favoris personnels). La bibliothèque Python standard contient de nombreux modules utiles, mais elle comprend également une véritable nécropole de code, un monument imposant de fragments obsolètes qui menacent d'enterrer leurs développeurs à tout moment.

Cependant, je pense que l'approche erronée peut être mise en œuvre dans cette phrase PEP. La bibliothèque standard est actuellement prise en charge en tandem avec les développeurs CPython. De gros morceaux étaient laissés dans le vague espoir que cela profiterait un jour à quelqu'un. Dans le PEP précité, ce principe peut être observé lors de la protection du module colorsys. Pourquoi ne pas le retirer? Réponse: «Ce module est nécessaire pour convertir les couleurs CSS entre les systèmes de coordonnées (RGB, YIQ, HSL et HSV). [Il] n'impose pas de coûts supplémentaires au développement principal. »

Il y avait des moments où l'accès à Internet était limité, et cela aurait pu être une bonne idée de pré-charger Python avec une tonne de matériel, mais de nos jours les modules nécessaires pour convertir les couleurs entre les différents systèmes de coordonnées sont à une étape de la commande pip install.

Pourquoi n'avez-vous pas considéré ma demande de pool?

Examinons donc cette affirmation: de minuscules modules comme colorsys imposent-ils des «coûts supplémentaires au développement principal»?

Il suffit que les principaux développeurs essaient de maintenir une base énorme et ancienne de code C, qui est CPython lui-même. Comme Marietta Viggia l'a dit dans son discours à North Bay Python, la question la plus fréquemment posée par les développeurs du noyau est: "Pourquoi n'avez-vous pas examiné ma demande de pool?" Et quelle est la réponse? Il est plus facile d'ignorer ces demandes de pool. C'est ce que signifie être développeur de noyau!

On pourrait se demander si Twisted a le même problème? Twisted est également une grande collection de modules à couplage lâche; une sorte de bibliothèque standard pour la mise en réseau. Sont tous ces clients et serveurs pour SSH, IMAP, HTTP, TLS, etc. etc. essayer de tout presser dans un seul paquet?

Obligé de répondre: oui . Twisted est monolithique car il provient de la même période historique que CPython, lorsque l'installation des composants était vraiment compliquée. Par conséquent, je sympathise avec la position de CPython.

Idéalement, à un moment donné, chaque sous-projet dans Twisted devrait devenir un projet distinct avec son propre référentiel, une intégration continue (CI), un site Web et, bien sûr, avec ses propres développeurs plus ciblés. Nous partageons déjà lentement mais sûrement des projets où une frontière naturelle peut être tracée. Certains des points qui ont commencé dans Twisted en tant que constants et incrémentiels sont séparés, différés et les chemins de fichiers sont en cours de séparation. D'autres projets, tels que klein et treq, continuent de vivre séparément. Nous ferons davantage lorsque nous découvrirons comment réduire les coûts de mise en place et de prise en charge de l'intégration continue et comment libérer l'infrastructure pour chacun d'eux.

Mais la nature monolithique de Twisted est-elle le problème le plus urgent ou même le plus grave pour le projet? Apprécions-le.

Au moment d'écrire ces lignes, Twisted avait 5 demandes de pool en attente non résolues en ligne. Le temps moyen consacré à l'examen d'un billet est, en gros, de quatre jours et demi. Le ticket le plus ancien de la file d'attente est daté du 22 avril, ce qui signifie que moins de 2 mois se sont écoulés depuis l'envoi de la demande de pool non révisée la plus ancienne.

Il est toujours difficile de trouver suffisamment de développeurs et de temps pour répondre aux demandes de pool. Parfois, il semble que nous recevions encore trop souvent la question "Pourquoi ne considérez-vous pas ma demande de pool?" Nous ne le faisons pas toujours parfaitement, mais en général nous gérons; la file d'attente oscille entre 0 et 25 environ au cours du mois le plus malchanceux.

Qu'en est-il du cœur de CPython par rapport à ces chiffres?

Après avoir visité le github , vous pouvez voir que 429 billets sont en attente de considération pour le moment. Le plus ancien d'entre eux est attendu à partir du 2 février 2018, soit près de 500 jours.

Combien de problèmes avec l'interpréteur et combien de problèmes avec la bibliothèque stdlib? De toute évidence, un examen en attente est un problème, mais la suppression de stdlib aidera-t-elle?

Pour une évaluation rapide et non scientifique, j'ai regardé la première (la plus ancienne) page de demandes de pool. Dans mon évaluation subjective, sur 25 demandes de pool, 14 étaient associées à la bibliothèque standard, 10 au noyau de la langue ou au code d'interprète, et une était associée à un petit problème de documentation. Sur la base de cette proportion, je me risquerais à suggérer qu'environ la moitié des demandes de pool non révisées sont associées au code de bibliothèque standard.

Ainsi, la première raison pour laquelle l'équipe principale de CPython doit cesser de prendre en charge la bibliothèque standard est qu'elle n'a littéralement aucune capacité physique à prendre en charge la bibliothèque standard. Ou, en d'autres termes, ils ne le soutiennent pas, et il ne reste plus qu'à l'admettre et à commencer à partager le travail.

C'est un fait qu'aucune des requêtes de pool ouvert CPython n'est associée au module colorsys. En effet, cela n'impose pas de coûts sur le développement du noyau. Le développement du noyau lui-même impose ces coûts. Si je voulais mettre à jour le module colorsys pour suivre le temps (peut-être pour avoir un objet Color, peut-être pour prendre en charge des modèles de couleurs entiers), je devrais probablement attendre 500 jours ou plus.

À la suite de tout cela, il est plus difficile de changer le code dans la bibliothèque standard, ce qui conduit à un moindre intérêt des utilisateurs à contribuer. Les versions peu fréquentes de CPython ralentissent également le développement de la bibliothèque et réduisent les avantages des commentaires des utilisateurs. Ce n'est pas un hasard si presque tous les modules de la bibliothèque standard ont activement pris en charge des alternatives tierces, et ce n'est pas la faute des développeurs stdlib. L'ensemble du processus est affiné pour stagner tous les modules stdlib sauf les plus couramment utilisés.

Nouveaux environnements, nouvelles exigences

Peut-être encore plus important est que la liaison de CPython à la bibliothèque standard place CPython lui-même dans une position privilégiée par rapport aux autres implémentations de langage.

Le podcast après le podcast , le podcast après le rapport, nous dit que pour continuer à réussir et développer Python, vous devez vous développer dans de nouveaux domaines: en particulier dans le front-end, ainsi que les clients mobiles, les systèmes embarqués et les jeux sur console.

Ces environnements nécessitent une ou deux conditions:

• un runtime complètement différent (voir Brython ou MicroPython )
• version allégée modifiée de la bibliothèque standard.

Dans tous ces cas, la pierre d'achoppement est la définition des modules qui doivent être supprimés de la bibliothèque standard. Ils doivent être trouvés par essais et erreurs; Tout d'abord, le processus est complètement différent du processus de détermination de dépendance standard dans une application Python. Il n'y a pas de déclaration install_requires dans setup.py signalant que la bibliothèque utilise un module de stdlib que le runtime Python cible peut ignorer en raison de l'espace limité.

Un problème peut survenir même si tout ce que nous utilisons est du Python standard sur une installation Linux. Même les distributions Linux pour les serveurs et les ordinateurs de bureau ont un besoin égal d'un plus petit package de noyau Python, donc la bibliothèque standard est déjà assez tronquée. Cela peut ne pas répondre aux exigences du code Python et, par conséquent, entraîner des erreurs lorsque même l' installation de pip ne fonctionnera pas .

Emportez tout

«Qu'en est-il de l'hypothèse selon laquelle vous devez nettoyer un peu chaque jour? Bien que cela semble convaincant, ne vous laissez pas tromper. La raison pour laquelle il vous semble que le nettoyage ne s'arrête jamais est précisément parce que vous nettoyez un peu. [...] Le principal secret du succès est le suivant: si vous le retirez d'un seul coup, et non progressivement, vous pouvez changer de façon permanente vos pensées et vos habitudes de vie »

Marie Kondo, nettoyage magique. L'art japonais de rétablir l'ordre chez soi et dans la vie "(p. 15-16)

Bien que la réduction progressive de la bibliothèque standard soit un pas dans la bonne direction, les changements graduels ne suffisent pas à eux seuls. Comme le dit Marie Kondo, si vous voulez vraiment mettre les choses en ordre, la première étape consiste à tout mettre hors de vue pour vraiment tout voir, puis à ne rendre que ce qui est nécessaire.

Le moment est venu de rendre hommage à ces modules qui ne sont plus encourageants et de les envoyer loin.
Nous avons besoin d'une version de Python contenant uniquement le minimum le plus nécessaire pour que toutes les implémentations puissent être cohérentes et pour que les applications (même celles qui fonctionnent dans les navigateurs Web ou les microcontrôleurs) puissent simplement indiquer leurs besoins dans requirements.txt.

Dans certains environnements commerciaux, l'idée d'avoir une énorme bibliothèque standard semble attrayante car l'ajout de dépendances dans requirements.txt est bureaucratique, cependant, la «bibliothèque standard» dans de tels environnements a des limites purement arbitraires.

Ce pourrait être une bonne idée de fournir certaines des distributions binaires de CPython (éventuellement même officielles) avec une large sélection de modules de PyPI. En effet, même pour les tâches ordinaires, une certaine quantité de la bibliothèque stdlib est requise, dont pip a besoin pour installer les autres modules nécessaires.

Il y a maintenant une situation où pip est distribué avec Python, mais n'est pas développé dans le référentiel CPython. Une partie de ce que le programme d'installation Python par défaut est fourni est développée dans le référentiel CPython, une partie est fournie dans une archive tar distincte pour l'interpréteur.

Pour utiliser Linux, nous avons besoin d'un support de démarrage avec une vaste gamme de programmes supplémentaires. Mais cela ne signifie pas que le noyau Linux lui-même se trouve dans un référentiel géant, dans lequel des centaines d'applications nécessaires à un serveur Linux fonctionnel sont développées par une seule équipe. Le noyau Linux est extrêmement précieux, mais les systèmes d'exploitation qui l'utilisent sont créés à partir d'une combinaison du noyau Linux et d'une large gamme de bibliothèques et de programmes développés séparément.

Conclusion

La philosophie «Batteries incluses» était parfaitement adaptée à sa création; comme une fusée d'appoint, il a livré Python au public de programmation. Cependant, à mesure que les écosystèmes open source et les packages Python arrivent à maturité, cette stratégie devient obsolète et, comme tout accélérateur, nous devons la laisser revenir au sol afin qu'elle ne nous ramène pas en arrière.

De nouveaux environnements d'exécution Python, de nouvelles tâches de déploiement et de nouveaux publics de développeurs offrent à la communauté Python de formidables opportunités pour atteindre de nouveaux sommets.

Mais pour y parvenir, nous avons besoin d'un nouveau cœur Python plus compact et non surchargé. Nous devons secouer toute la bibliothèque standard au sol, ne laissant que les plus petites pièces dont nous avons besoin pour pouvoir dire: c'est vraiment nécessaire, mais c'est juste agréable à avoir.

J'espère avoir convaincu au moins certains d'entre vous de quel noyau Python nous avons besoin.

Et maintenant: qui veut écrire PEP ?