Auf dem Weg zum Python-Kern

Hallo Habr! Ich präsentiere Ihnen die Übersetzung von Toward, einem "Kernel Python" -Artikel von Glyph Lefkowitz (Schöpfer des Twisted Frameworks).

Weitere Details - unter dem Schnitt.

Die Magie der Minimierung der Standardbibliothek

Unter dem Einfluss von Amber Browns Rede im letzten Monat auf dem Python Language Summit (unter Bezugnahme auf ihren Mai-Bericht "Batterien sind eingeschaltet, aber sie lecken" - Kommentar des Übersetzers) setzte Christian Hymes seine Arbeit zur Reduzierung der Standard-Python-Bibliothek fort und erstellte einen PEP 594- Vorschlag zur expliziten Entfernung veraltete und nicht unterstützte Fragmente davon.

Das Aufkommen von PEP 594 („Entfernen leerer Batterien aus der Standardbibliothek“) ist eine gute Nachricht für Pythonisten, insbesondere für diejenigen, die die Standardbibliothek unterstützen und nun ein kleineres Frontend haben werden. Ein kurzer Rundgang durch die PEP-Galerie veralteter oder entfernungsbasierter Module spricht für sich (die Module Sunau, Xdrlib und Chunk sind meine persönlichen Favoriten). Die Standard-Python-Bibliothek enthält viele nützliche Module, enthält jedoch auch eine echte Code-Nekropole, ein hoch aufragendes Denkmal veralteter Fragmente, die ihre Entwickler jederzeit zu begraben drohen.

Ich glaube jedoch, dass der fehlerhafte Ansatz in diesem PEP-Satz implementiert werden kann. Die Standardbibliothek wird derzeit zusammen mit CPython-Entwicklern unterstützt. Große Teile davon blieben in der vagen Hoffnung zurück, dass es eines Tages jemandem nützen würde. In dem oben erwähnten PEP kann dieses Prinzip beim Schutz des Farbenmoduls beachtet werden. Warum nicht entfernen? Antwort: „Dieses Modul wird benötigt, um CSS-Farben zwischen Koordinatensystemen (RGB, YIQ, HSL und HSV) zu konvertieren. [Er] erlegt der Kernentwicklung keine zusätzlichen Kosten auf. “

Es gab Zeiten, in denen der Internetzugang eingeschränkt war, und es war vielleicht eine gute Idee, Python mit einer Menge Material vorzuladen, aber heutzutage sind die Module, die zum Konvertieren von Farben zwischen verschiedenen Koordinatensystemen benötigt werden, nur einen Schritt vom Befehl pip install entfernt.

Warum haben Sie meine Poolanfrage nicht berücksichtigt?

Schauen wir uns also diese Aussage an: Verursachen winzige Module wie colorys „zusätzliche Kosten für die Kernentwicklung“?

Für die Hauptentwickler ist es genug, dass sie versuchen, eine riesige und alte Basis von C-Code zu erhalten, nämlich CPython selbst. Wie Marietta Viggia in ihrer Rede bei North Bay Python sagte, lautet die häufigste Frage von Kernel-Entwicklern: "Warum haben Sie sich meine Pool-Anfrage nicht angesehen?" Und wie lautet die Antwort? Es ist einfacher, diese Poolanforderungen zu ignorieren. Das bedeutet es, ein Kernel-Entwickler zu sein!

Man könnte fragen, hat Twisted das gleiche Problem? Twisted ist auch eine große Sammlung lose gekoppelter Module. eine Art Standardbibliothek für die Vernetzung. Sind alle diese Clients und Server für SSH, IMAP, HTTP, TLS usw. usw. versuchen, alles in einem Paket zusammenzudrücken?

Zur Antwort gezwungen: ja . Twisted ist monolithisch, da es aus derselben historischen Zeit stammt wie CPython, als die Installation von Komponenten sehr kompliziert war. Daher sympathisiere ich mit der Position von CPython.

Im Idealfall sollte jedes Teilprojekt in Twisted irgendwann zu einem separaten Projekt mit einem eigenen Repository, einer kontinuierlichen Integration (CI), einer Website und natürlich mit eigenen, stärker fokussierten Entwicklern werden. Wir teilen bereits langsam aber sicher Projekte, bei denen eine natürliche Grenze gezogen werden kann. Einige der Punkte, die in Twisted als konstant und inkrementell gestartet wurden, werden getrennt, zurückgestellt und der Dateipfad wird getrennt. Andere Projekte wie klein und treq leben weiterhin getrennt. Wir werden mehr tun, wenn wir herausfinden, wie wir die Kosten für die Einrichtung und Unterstützung einer kontinuierlichen Integration senken und die Infrastruktur für jeden von ihnen freigeben können.

Aber ist die monolithische Natur von Twisted das dringendste oder sogar schwerwiegendste Problem für das Projekt? Lass es uns schätzen.

Zum Zeitpunkt dieses Schreibens hatte Twisted 5 ungelöste ausstehende Pool-Anfragen in der Schlange. Die durchschnittliche Zeit, die für die Prüfung eines Tickets aufgewendet wird, beträgt ungefähr viereinhalb Tage. Das älteste Ticket in der Warteschlange ist auf den 22. April datiert. Dies bedeutet, dass weniger als 2 Monate vergangen sind, seit die älteste nicht überprüfte Poolanforderung gesendet wurde.

Es ist immer schwierig, genügend Entwickler und Zeit zu finden, um auf Pool-Anfragen zu antworten. Manchmal scheint es, dass wir immer noch zu oft die Frage bekommen "Warum erwägst du nicht meine Poolanfrage?" Wir machen es nicht immer perfekt, aber im Allgemeinen schaffen wir es; Die Warteschlange schwankt im unglücklichsten Monat zwischen 0 und 25.

Was ist mit dem Kern von CPython im Vergleich zu diesen Zahlen?

Nachdem Sie den Github besucht haben , können Sie sehen, dass derzeit 429 Tickets auf Ihre Prüfung warten. Der älteste von ihnen wird ab dem 2. Februar 2018 erwartet, d. H. Fast 500 Tage.

Wie viele Probleme mit dem Interpreter und wie viele Probleme mit der stdlib-Bibliothek? Natürlich ist eine ausstehende Überprüfung ein Problem, aber hilft die Entfernung von stdlib?

Für eine schnelle und unwissenschaftliche Beurteilung habe ich mir die erste (älteste) Seite der Poolanfragen angesehen. Nach meiner subjektiven Einschätzung waren von 25 Poolanfragen 14 mit der Standardbibliothek verknüpft, 10 mit dem Kern der Sprache oder dem Interpretercode und eine mit einem kleinen Dokumentationsproblem. Auf der Grundlage dieses Anteils würde ich vorschlagen, dass ungefähr die Hälfte der nicht überprüften Poolanforderungen mit dem Standardbibliothekscode verknüpft ist.

Der erste Grund, warum das CPython-Hauptteam die Unterstützung der Standardbibliothek einstellen muss, ist, dass es buchstäblich keine physische Fähigkeit hat, die Standardbibliothek zu unterstützen. Oder mit anderen Worten, sie unterstützen es nicht, und es bleibt nur, es zuzugeben und zu beginnen, die Arbeit zu teilen.

Es ist eine Tatsache, dass keine der CPython Open Pool-Anforderungen dem Farben-Modul zugeordnet ist. In der Tat verursacht es keine Kosten für die Entwicklung des Kernels. Die Kernel-Entwicklung selbst verursacht diese Kosten. Wenn ich das colorys-Modul aktualisieren wollte, um auf dem neuesten Stand zu bleiben (möglicherweise um ein Color-Objekt zu haben, möglicherweise um ganzzahlige Farbmodelle zu unterstützen), müsste ich höchstwahrscheinlich 500 Tage oder länger warten.

Infolgedessen ist es schwieriger, den Code in der Standardbibliothek zu ändern, was zu einem geringeren Interesse der Benutzer an Beiträgen führt. Seltene Versionen von CPython verlangsamen auch die Bibliotheksentwicklung und verringern die Vorteile von Benutzer-Feedback. Es ist kein Zufall, dass fast alle Module der Standardbibliothek aktiv Alternativen von Drittanbietern unterstützt haben, und dies ist nicht die Schuld der stdlib-Entwickler. Der gesamte Prozess wird geschärft, um alle bis auf die am häufigsten verwendeten stdlib-Module zu stagnieren.

Neue Umgebungen, neue Anforderungen

Noch wichtiger ist vielleicht, dass die Verknüpfung von CPython mit der Standardbibliothek CPython selbst im Vergleich zu anderen Sprachimplementierungen in eine privilegierte Position bringt.

Der Podcast nach dem Podcast , der Podcast nach dem Bericht, sagt uns, dass Sie in neuen Bereichen wachsen müssen, um weiterhin erfolgreich zu sein und Python zu entwickeln: insbesondere im Front-End sowie bei mobilen Clients, eingebetteten Systemen und Konsolenspielen.

Diese Umgebungen erfordern eine oder zwei Bedingungen:

• eine völlig andere Laufzeit (siehe Brython oder MicroPython )
• modifizierte abgespeckte Version der Standardbibliothek.

In all diesen Fällen ist der Stolperstein die Definition von Modulen, die aus der Standardbibliothek entfernt werden müssen. Sie müssen durch Versuch und Irrtum gefunden werden; Erstens unterscheidet sich der Prozess vollständig vom Standardprozess zur Bestimmung der Abhängigkeit in einer Python-Anwendung. In setup.py gibt es keine install_requires-Deklaration, die angibt, dass die Bibliothek ein Modul aus stdlib verwendet, das die Python-Ziellaufzeit aufgrund von Speicherplatzbeschränkungen möglicherweise überspringt.

Ein Problem kann auftreten, selbst wenn bei einer Linux-Installation nur Standard-Python verwendet wird. Sogar Linux-Distributionen für Server und Desktop-Computer benötigen gleichermaßen ein kleineres Python-Kernel-Paket, sodass die Standardbibliothek in ihnen bereits ziemlich abgeschnitten ist. Dies entspricht möglicherweise nicht den Anforderungen des Python-Codes und führt daher zu Fehlern, wenn selbst die Pip-Installation nicht funktioniert .

Nimm alles weg

„Was ist mit der Annahme, dass Sie jeden Tag ein wenig putzen müssen? Lassen Sie sich nicht täuschen, auch wenn es überzeugend klingt. Der Grund, warum es Ihnen so scheint, als würde die Reinigung niemals enden, liegt genau darin, dass Sie ein wenig putzen. [...] Das Hauptgeheimnis des Erfolgs ist folgendes: Wenn Sie es auf einen Schlag und nicht allmählich entfernen, können Sie Ihr Denken und Ihre Lebensgewohnheiten dauerhaft ändern. “

Marie Kondo, Magische Reinigung. Die japanische Kunst, die Ordnung zu Hause und im Leben wiederherzustellen "(S. 15-16)

Während die schrittweise Reduzierung der Standardbibliothek ein Schritt in die richtige Richtung ist, reichen schrittweise Änderungen allein nicht aus. Wie Marie Kondo sagt, wenn Sie die Dinge wirklich in Ordnung bringen wollen, besteht der erste Schritt darin, alles außer Sichtweite zu bringen, um wirklich alles zu sehen, und dann nur das zurückzugeben, was benötigt wird.

Es ist an der Zeit, den Modulen, die nicht mehr ermutigend sind, Tribut zu zollen und sie weit zu schicken.
Wir benötigen eine Version von Python, die nur das notwendigste Minimum enthält, damit alle Implementierungen konsistent sind und Anwendungen (auch solche, die in Webbrowsern oder Mikrocontrollern funktionieren) ihre Anforderungen einfach in der Datei "resources.txt" angeben können.

In einigen Geschäftsumgebungen scheint die Idee einer riesigen Standardbibliothek attraktiv zu sein, da das Hinzufügen von Abhängigkeiten in der Anforderung.txt bürokratisch ist. Die „Standardbibliothek“ in solchen Umgebungen hat jedoch rein willkürliche Grenzen.

Es könnte immer noch eine gute Idee sein, einige der Binärdistributionen von CPython (möglicherweise sogar offizielle) mit einer großen Auswahl an Modulen von PyPI zu versorgen. Selbst für normale Aufgaben ist eine bestimmte Menge der stdlib-Bibliothek erforderlich, die pip benötigt, um andere erforderliche Module zu installieren.

Jetzt gibt es eine Situation, in der pip zusammen mit Python verteilt wird, aber nicht im CPython-Repository entwickelt wird. Ein Teil dessen, was das Standard-Python-Installationsprogramm enthält, wird im CPython-Repository entwickelt, ein Teil in einem separaten Tarball für den Interpreter.

Um Linux verwenden zu können, benötigen wir bootfähige Medien mit einer Vielzahl zusätzlicher Programme. Dies bedeutet jedoch nicht, dass sich der Linux-Kernel selbst in einem riesigen Repository befindet, in dem Hunderte von Anwendungen, die für einen funktionierenden Linux-Server benötigt werden, von einem Team entwickelt werden. Der Linux-Kernel ist äußerst wertvoll, aber die Betriebssysteme, die ihn verwenden, werden aus einer Kombination des Linux-Kernels und einer Vielzahl separat entwickelter Bibliotheken und Programme erstellt.

Fazit

Die Philosophie „Batterien eingeschlossen“ war ideal für ihre Erstellung geeignet. Wie eine Booster-Rakete lieferte sie Python an die Programmierer. Mit zunehmender Reife von Open-Source-Ökosystemen und Python-Paketen wird diese Strategie jedoch veraltet, und wie bei jedem Beschleuniger müssen wir sie auf den Boden zurückkehren lassen, damit sie uns nicht zurückzieht.

Neue Python-Laufzeiten, neue Bereitstellungsaufgaben und neue Entwicklergruppen bieten der Python-Community enorme Möglichkeiten, neue Höhen zu erreichen.

Um dies zu erreichen, benötigen wir jedoch einen neuen, kompakteren und nicht überlasteten Python-Kern. Wir müssen die gesamte Standardbibliothek auf den Boden schütteln und nur die kleinsten Teile übrig lassen, damit wir sagen können: Das ist wirklich notwendig, aber es ist einfach schön zu haben.

Ich hoffe, dass ich zumindest einige von Ihnen davon überzeugt habe, welchen Python-Kern wir brauchen.

Und jetzt: Wer will PEP schreiben?