Erforderliche Attribute

Dies sind Attribute in sys.implementation, auf die sich die Standardbibliothek und die Sprachdefinition verlassen werden, was bedeutet, dass Implementierer sie definieren müssen.

name

Ein Kleinbuchstaben-Bezeichner, der die Implementierung darstellt. Beispiele sind ‚pypy‘, ‚jython‘, ‚ironpython‘ und ‚cpython‘.

version

Die Version der Implementierung, im Gegensatz zur Version der Sprache, die sie implementiert. Dieser Wert entspricht dem Format, das in Versionsformat beschrieben wird.

hexversion

Die Version der Implementierung im selben hexadezimalen Format wie sys.hexversion.

cache_tag

Ein String, der für den Cache-Tag von PEP 3147 verwendet wird. Es wäre normalerweise eine Kombination aus Name und Version (z.B. ‚cpython-33‘ für CPython 3.3). Eine Implementierung kann jedoch explizit einen anderen Cache-Tag verwenden. Wenn cache_tag auf None gesetzt ist, bedeutet dies, dass die Modul-Cache-Funktion deaktiviert werden sollte.

Hinzufügen neuer erforderlicher Attribute

Im Laufe der Zeit werden weitere erforderliche Attribute zu sys.implementation hinzugefügt. Jedes muss jedoch einen sinnvollen Anwendungsfall über alle Python-Implementierungen hinweg haben, um berücksichtigt zu werden. Dies wird am deutlichsten durch einen Anwendungsfall in der Standardbibliothek oder in der Sprachenspezifikation.

Alle Vorschläge für neue erforderliche Attribute durchlaufen den normalen PEP-Prozess. Ein solcher PEP muss nicht lang sein, nur ausreichend. Er muss die Begründung für das neue Attribut, seine Anwendungsfälle und die Auswirkungen, die es auf die verschiedenen Python-Implementierungen haben wird, ausreichend darlegen.

Versionsformat

Ein Hauptpunkt von sys.implementation ist die Speicherung von Informationen, die intern in der Standardbibliothek verwendet werden. Um die Nützlichkeit des Versionsattributs zu erleichtern, sollte dessen Wert über Implementierungen hinweg in einem konsistenten Format vorliegen.

Somit folgt das Format von sys.implementation.version dem von sys.version_info, was im Wesentlichen ein benanntes Tupel ist. Es ist ein vertrautes Format und im Allgemeinen konsistent mit normalen Konventionen für Versionsformate.

Typüberlegungen

Es ist sehr einfach, sich in Diskussionen über den Typ von sys.implementation zu verlieren. Sein Zweck ist es jedoch, die Standardbibliothek und die Sprachdefinition zu unterstützen. Daher ist nicht viel wirklich wichtig in Bezug auf seinen Typ, im Gegensatz zu einer Funktion, die allgemeiner verwendet würde. So wurden Merkmale wie Unveränderlichkeit und Sequenzhaftigkeit außer Acht gelassen.

Die einzige wirkliche Wahl war zwischen einem Objekt mit Attributzugriff und einem Mapping mit Elementzugriff. Dieser PEP setzt auf Punktnotation, um die relativ feste Natur des Namensraums widerzuspiegeln.

Nicht erforderliche Attribute

Frühere Versionen dieses PEP enthielten ein erforderliches Attribut namens metadata, das alle nicht erforderlichen, implementierungsspezifischen Daten enthielt [12]. Dies erwies sich jedoch als unnötige Ergänzung angesichts des Zwecks von sys.implementation.

Letztendlich werden nicht erforderliche Attribute in diesem PEP praktisch ignoriert. Sie haben keine Auswirkungen, außer dass eine fahrlässige Nutzung mit zukünftigen erforderlichen Attributen kollidieren könnte. Das ist jedoch nur ein geringfügiges Problem für sys.implementation.

Warum ein Teil von sys?

Das sys-Modul enthält den neuen Namensraum, da sys die Sammelstelle für interpretermäßige Variablen und Funktionen ist. Viele implementierungsspezifische Attribute sind bereits in sys zu finden.

Warum strenge Einschränkungen für Werte?

Wie bereits in Versionsformat erwähnt, sind die Werte in sys.implementation für die Verwendung durch die Standardbibliothek bestimmt. Die Einschränkung dieser Werte, im Wesentlichen eine API für sie festzulegen, ermöglicht deren konsistente Verwendung, unabhängig davon, wie sie sonst implementiert sind. Es sollte jedoch darauf geachtet werden, die Einschränkungen nicht zu übermäßig festzulegen.

platform.python_implementation()

„Explizit ist besser als implizit“

Das platform-Modul ermittelt die Python-Implementierung, indem es nach Hinweisen in einigen sys-Variablen sucht [9]. Dieser Ansatz ist jedoch fragil und erfordert Änderungen an der Standardbibliothek, jedes Mal wenn sich eine Implementierung ändert. Darüber hinaus ist die Unterstützung in platform auf die Implementierungen beschränkt, die die Kernentwickler durch spezielle Behandlung im platform-Modul gesegnet haben.

Mit sys.implementation würden die verschiedenen Implementierungen die Werte in ihrer eigenen Version des sys-Moduls *explizit* setzen.

Ein weiteres Bedenken ist, dass das platform-Modul Teil der Standardbibliothek ist, die idealerweise Implementierungsdetails minimieren sollte, wie sie in sys.implementation verschoben würden.

Jede Überschneidung zwischen sys.implementation und dem platform-Modul würde einfach an sys.implementation delegieren (mit derselben Schnittstelle in platform, die es umschließt).

Cache-Tag-Generierung in Frozen Importlib

PEP 3147 definierte die Verwendung eines Modul-Caches und von Cache-Tags für Dateinamen. Der Importlib-Bootstrap-Code, der ab Version 3.3 in das Python-Binärprogramm eingefroren ist, verwendet die Cache-Tags während des Importvorgangs. Ein Teil des Projekts zur Bootstrapping von Importlib war die Bereinigung von Code aus Python/import.c, der nicht mehr benötigt wurde.

Der in Python/import.c definierte Cache-Tag war fest kodiert auf "cpython" MAJOR MINOR. Für Importlib besteht die Wahl darin, ihn auf dieselbe Weise fest zu kodieren oder die Implementierung so zu erraten, wie es platform.python_implementation() tut.

Solange der fest kodierte Tag auf CPython-spezifischen Code beschränkt ist, ist er akzeptabel. Insofern jedoch andere Python-Implementierungen den Importlib-Code zur Arbeit mit dem Modul-Cache verwenden, würde ein fest kodierter Tag zu einem Problem werden.

Die direkte Verwendung des platform-Moduls ist in diesem Fall keine Option. Jedes Modul, das im Importlib-Bootstrap verwendet wird, muss integriert oder eingefroren sein, was für das platform-Modul nicht zutrifft. Dies ist der Punkt, der zum jüngsten Interesse an sys.implementation führte.

Unabhängig vom Ergebnis für den verwendeten Implementierungsnamen betrifft ein weiteres Problem die Version, die im Cache-Tag verwendet wird. Diese Version ist wahrscheinlich die Implementierungsversion und nicht die Sprachversion. Die Implementierungsversion ist jedoch nirgendwo in der Standardbibliothek ohne Weiteres erkennbar.

Implementierungsspezifische Tests

Derzeit gibt es eine Reihe von implementierungsspezifischen Tests in der Testsuite unter Lib/test. Das Testunterstützungsmodul (Lib/test/support.py) bietet einige Funktionalitäten für den Umgang mit diesen Tests. Ähnlich wie das platform-Modul muss test.support jedoch einige Vermutungen anstellen, die durch sys.implementation überflüssig würden.

Jythons os.name Hack

In Jython ist os.name auf ‚java‘ gesetzt, um eine spezielle Behandlung der Java-Umgebung in der Standardbibliothek zu ermöglichen [10] [11]. Leider maskiert dies den Betriebssystemnamen, der dort sonst stehen würde. sys.implementation würde helfen, die Notwendigkeit dieser Sonderbehandlung zu vermeiden. Derzeit setzt Jython os._name für den normalen Wert von os.name.

Das Problem mit sys.(version|version_info|hexversion)

Frühere Versionen dieses PEP machten den Fehler, sys.version_info (und ähnliche) als Version der Python-Sprache im Gegensatz zur Implementierung zu bezeichnen. Dies ist jedoch nicht der Fall. Stattdessen ist es die Version der CPython-Implementierung. Nebenbei bemerkt, spiegeln die ersten beiden Komponenten von sys.version_info (Major und Minor) auch die Version der Sprachdefinition wider.

Wie Barry Warsaw bemerkte, waren die „Semantiken von sys.version_info in der Vergangenheit ausreichend schwammig“ [13]. Mit sys.implementation haben wir die Möglichkeit, diese Situation zu verbessern, indem wir zunächst einen expliziten Ort für die Version der Implementierung festlegen.

Dieser PEP unternimmt keine weiteren Anstrengungen, um die Semantik von sys.version_info direkt zu klären. Unabhängig davon wird eine explizite Version für die Implementierung sicherlich dazu beitragen, die Unterscheidung von der Sprachversion zu verdeutlichen.

IronPython

Jeff Hardy antwortete auf eine Bitte um Feedback [4]. Er sagte: „Ich werde es wahrscheinlich am Tag nach der Genehmigung hinzufügen“ [5]. Er gab auch nützliches Feedback sowohl zum Typ von sys.implementation als auch zum metadata-Attribut (das inzwischen aus dem PEP entfernt wurde).

Jython

2009 sagte Frank Wierzbicki Folgendes (bezüglich Jythons Implementierung der erforderlichen Attribute) [6]

Speaking for Jython, so far it looks like something we would adopt
soonish after it was accepted (it looks pretty useful to me).

PyPy

Einige der PyPy-Entwickler haben auf eine Bitte um Feedback reagiert [7]. Armin Rigo sagte Folgendes [8]

For myself, I can only say that it looks like a good idea, which we
will happily adhere to when we migrate to Python 3.3.

Er unterstützte auch die Beibehaltung einer kleinen Liste von erforderlichen Attributen. Sowohl Armin als auch Laura Creighton wiesen darauf hin, dass eine Bemühung zur besseren Katalogisierung von Python-Implementierungen willkommen wäre. Eine solche Bemühung, zu der dieser PEP einen kleinen Anfang darstellt, wird separat betrachtet.

PEP 3139

PEP 3139 empfahl 2008 eine Bereinigung des sys-Moduls, teilweise durch die Extraktion implementierungsspezifischer Variablen und Funktionen in ein separates Modul. PEP 421 ist eine weniger ambitionierte Version dieser Idee. Obwohl PEP 3139 abgelehnt wurde, spiegeln sich seine Ziele zu einem großen Teil in PEP 421 wider, allerdings mit einem deutlich leichteren Ansatz.

PEP 399

PEP 399 gibt die Politik bezüglich der Standardbibliothek vor und hilft, sie besser an alternative Implementierungen anzupassen. PEP 421 wird in diesem Sinne vorgeschlagen.