PEP 641 – Verwendung eines Unterstrichs im Versionsanteil von Python 3.10-Kompatibilitätstags
- Autor:
- Brett Cannon <brett at python.org>, Steve Dower <steve.dower at python.org>, Barry Warsaw <barry at python.org>
- PEP-Delegate:
- Pablo Galindo <pablogsal at python.org>
- Discussions-To:
- Discourse thread
- Status:
- Abgelehnt
- Typ:
- Standards Track
- Erstellt:
- 20-Okt-2020
- Python-Version:
- 3.10
- Post-History:
- 21-Okt-2020
- Resolution:
- Discourse-Nachricht
Zusammenfassung
Hinweis
Dieser PEP wurde aufgrund potenzieller Bruchstellen in der Community abgelehnt.
Unter Verwendung des Tag-Systems, das in PEP 425 (hauptsächlich für Wheel-Dateinamen verwendet) beschrieben ist, gibt jede Python-Version Kompatibilitätstags an (z. B. cp39, py39 für CPython 3.9). Für CPython 3.10 schlägt dieser PEP die Verwendung von 3_10 als Versionsanteil der Tags (anstelle von 310) vor.
Motivation
Bis zu diesem Zeitpunkt war der Versionsanteil der Kompatibilitätstags, die z. B. in Wheel-Dateinamen verwendet werden, eine direkte Aneinanderreihung der Major- und Minor-Versionen von Python, sowohl für den CPython-Interpreter-Tag als auch für den generischen, interpreteragnostischen Interpreter-Tag (z. B. cp39 und py39). Dies gilt auch für den ABI-Tag (z. B. cp39). Dank der Tatsache, dass sowohl die Major- als auch die Minor-Versionen einstellig sind, war es eindeutig, welche Ziffer in z. B. 39 was darstellte.
Aber beginnend mit Python 3.10 entsteht Mehrdeutigkeit, da 310 nicht klar unterscheidet, ob die Python-Version 3.10, 31.0 oder 310 als reine Major-Version von Python ist. Daher disambiguiert die Verwendung von 3_10, um Major/Minor-Teile zu trennen, wie von PEP 425 erlaubt, die unterstützte Python-Version.
Begründung
Die Verwendung von 3_10 anstelle eines anderen vorgeschlagenen Trennzeichens ist eine Einschränkung von PEP 425, daher sind die einzigen Optionen 3_10 oder 310.
Spezifikation
Die Konfigurationsvariable SOABI und sysconfig.get_config_var('py_version_nodot') werden aktualisiert, um 3_10 entsprechend zu verwenden.
Abwärtskompatibilität
Tools, die auf dem Projekt „packaging“ [2] basieren, erwarten bereits eine Versionsspezifikation von 3_10 für Python 3.10. Würde die Versionsspezifikation bei 310 bleiben, müsste diese Änderung rückgängig gemacht und abhängige Projekte (z. B. pip) aktualisiert werden.
Der Wechsel zu 3_10 wirkt sich auf alle Tools aus, die implizit auf der Konvention basieren, dass die Minor-Version eine einzelne Ziffer ist. Diese sind jedoch unabhängig von jeder hier vorgenommenen Änderung fehlerhaft.
Für Tools, die davon ausgehen, dass die Major-Version nur die erste Ziffer ist, müssen diese aktualisiert werden, wenn wir zu 3_10 wechseln.
In nicht-lokaler ASCII sortiert _ nach jeder Ziffer, so dass die lexikografische Sortierung, die einer Sortierung nach Python-Version eines Wheel-Dateinamens entspricht, beibehalten wird.
Da PEP 515 (Python 3.6) Unterstriche in numerischen Literalen ignoriert. Das bedeutet, dass int("3_10") und int("310") das gleiche Ergebnis liefern und die Sortierung basierend auf der Konvertierung in eine Ganzzahl beibehalten wird. **Jedoch** ist dies immer noch eine schlechte Art, Tags zu sortieren, und der Punkt wird hier nur erwähnt, um zu zeigen, dass dieser Vorschlag die Dinge nicht schlechter macht.
Sicherheitsimplikationen
Es gibt keine bekannten Sicherheitsbedenken.
Wie man das lehrt
Da die Verwendung des Interpreter-Tags meist maschinell erfolgt und dieser PEP eine Disambiguierung vornimmt, sollten keine besonderen Lehrüberlegungen erforderlich sein.
Referenzimplementierung
Ein Pull-Request [1] existiert bereits, der die Unterstützung für CPython 3.10 hinzufügt. Die Unterstützung für das Lesen von Wheel-Dateien mit diesem vorgeschlagenen PEP ist bereits implementiert.
Abgelehnte Ideen
Die Änderung nicht vornehmen
Es wurde erwogen, den Tag nicht zu ändern und bei 310 zu bleiben. Das Argument war, dass es weniger Arbeit macht und keine bestehenden Werkzeuge bricht. Aber am Ende wurde gedacht, dass die Disambiguierung besser ist.
Offene Fragen
Wie weit sollen wir das treiben?
Andere Stellen, an denen die Major- und Minor-Version verwendet werden, könnten ebenfalls aktualisiert werden, um einen Unterstrich zu verwenden (z. B. .pyc-Dateien, der Importpfad zur Zip-Datei für die Standardbibliothek). Es ist nicht bekannt, wie nützlich es wäre, dies allgegenwärtig zu machen.
Standardisierung auf zweistellige Minor-Versionsnummern
Ein alternativer Vorschlag wurde gemacht, um zu disambiguieren, wo die Major- und Minor-Versionen beginnen/enden, indem die Minor-Version immer zweistellig gemacht wird, gegebenenfalls mit einer 0 aufgefüllt. Die Vorteile davon sind, dass der aktuelle cp310 Interpreter-Tag korrekt ist und somit Bruchstellen minimiert werden. Er differenziert auch für die Zukunft.
Es gibt jedoch ein paar Nachteile. Einerseits existiert die Disambiguierung nur, *wenn* man weiß, dass die Minor-Versionsnummer zweistellig ist; im Vergleich dazu ist cp3_10 unabhängig von Ihrem Grundwissen eindeutig. Das Potenzial für eine dreistellige Minor-Versionsnummer wird durch diese zweistellige Anforderung ebenfalls nicht berücksichtigt.
Es gibt auch das Problem, dass andere Interpreter die Praxis in der Vergangenheit, Gegenwart oder Zukunft nicht befolgen. Es ist beispielsweise unbekannt, ob andere Personen zuvor einen dreistelligen Versionsanteil des Interpreter-Tags für einen anderen Interpreter verwendet haben, bei dem diese Regel falsch wäre. Diese Änderung würde auch darauf hindeuten, dass Interpreter, die derzeit eine einstellige Minor-Version haben – z. B. PyPy 7.3 – von pp73 auf pp703 wechseln oder den Wechsel ab ihrer nächsten Minor-Version (z. B. 7.4 oder 8.0) vornehmen. Andernfalls würde dies diese Regel exklusiv für den cp-Interpreter-Typ machen, was für die Leute verwirrender wäre.
Referenzen
Urheberrecht
Dieses Dokument wird in die Public Domain oder unter die CC0-1.0-Universal-Lizenz gestellt, je nachdem, welche Lizenz permissiver ist.
Quelle: https://github.com/python/peps/blob/main/peps/pep-0641.rst
Zuletzt geändert: 2025-02-01 08:55:40 GMT