Zusammenfassung

Dieser PEP beschreibt das Verhalten von Python-Skripten, wenn der Befehl python aufgerufen wird. Abhängig von der Distribution oder Systemkonfiguration ist python möglicherweise installiert oder auch nicht. Wenn python installiert ist, kann sein Zielinterpreter auf python2 oder python3 verweisen. Endbenutzer sind sich dieser Inkonsistenz über Unix-ähnliche Systeme hinweg möglicherweise nicht bewusst. Ziel dieses PEP ist es, die Verwirrung der Benutzer darüber zu reduzieren, worauf python verweist und wie sich das Skript verhält.

Die Empfehlungen im nächsten Abschnitt dieses PEP beschreiben das Verhalten beim

• Verwenden von virtuellen Umgebungen
• Schreiben von plattformübergreifenden Skripten mit Shebangs für python2 oder python3

Das Ziel des PEP ist es, das Verhalten für Skript-Endbenutzer, Distributionsanbieter und Skript-Wartungs-/Autoren zu klären.

Empfehlung

Unsere Empfehlungen sind unten aufgeführt. Wir weisen auf alle Erwartungen hin, auf denen diese Empfehlungen basieren.

Historie dieses PEP

Im Jahr 2011 aliasierten die meisten Distributionen den Befehl python auf Python 2, aber einige begannen, ihn auf Python 3 umzustellen ([5]). Da einige der früheren Distributionen standardmäßig keinen python2-Befehl bereitstellten, gab es zuvor keine Möglichkeit, Python 2-Code (oder beliebigen Code, der den Python 2-Interpreter direkt anstatt über sys.executable aufruft) ohne Modifikation zuverlässig auf allen Unix-ähnlichen Systemen auszuführen, da der Befehl python auf einigen Systemen die falsche Interpreterversion aufrief und der Befehl python2 auf anderen komplett fehlschlug. Dieser PEP bot ursprünglich einen sehr einfachen Mechanismus, um die plattformübergreifende Unterstützung mit minimalem zusätzlichem Aufwand für die Distributionswartung wiederherzustellen. Vereinfacht ausgedrückt war die Empfehlung:

1. Der Befehl python wurde für Code bevorzugt, der sowohl mit Python 2 als auch mit 3 kompatibel ist (da er auf allen Systemen verfügbar war, auch auf denen, die ihn bereits auf Python 3 aliasierten).
2. Der Befehl python sollte immer Python 2 aufrufen (um schwer zu diagnostizierende Fehler zu vermeiden, wenn Python 2-Code auf Python 3 ausgeführt wird).
3. Die Befehle python2 und python3 sollten verfügbar sein, um die Version explizit anzugeben.

Diese Empfehlungen setzten jedoch implizit voraus, dass Python 2 immer verfügbar sein würde. Da sich Python 2 seinem Lebensende im Jahr 2020 nähert (PEP 373, PEP 404), machen Distributionen Python 2 optional oder entfernen es ganz. Das bedeutet entweder das Entfernen des Befehls python oder dessen Umstellung auf Python 3. Einige Distributoren entschieden auch, dass ihre Benutzer besser bedient wären, wenn sie die ursprünglichen Empfehlungen des PEP ignorieren und Systemadministratoren die Freiheit geben, ihre Systeme entsprechend den Anforderungen ihrer jeweiligen Umgebung zu konfigurieren.

Aktuelle Begründung

Seit 2019 ist die Aktivierung einer virtuellen Python-Umgebung (oder ihres funktionalen Äquivalents) vor der Skriptausführung eine Möglichkeit, eine konsistente plattform- und distributionsübergreifende Erfahrung zu erzielen.

Folglich können Publisher davon ausgehen, dass Benutzer der Software eine geeignete Ausführungsumgebung bereitstellen.

Zukünftige Änderungen an dieser Empfehlung

Diese Empfehlung wird in den nächsten Jahren regelmäßig überprüft und aktualisiert, wenn das Kernentwicklungsteam dies für angemessen hält. Als Referenz werden reguläre Wartungs-Releases für die Python 2.7-Serie bis Januar 2020 fortgesetzt.

Migrationshinweise

Dieser Abschnitt enthält keine offiziellen Empfehlungen der CPython-Kernentwickler. Es handelt sich lediglich um eine Sammlung von Notizen zu verschiedenen Aspekten der Migration zu Python 3 als Standardversion von Python für ein System. Sie werden hoffentlich für Distributionen hilfreich sein, die eine solche Änderung in Erwägung ziehen.

• Die Haupthürde für eine Distribution, den Befehl python von python2 auf python3 umzustellen, ist nicht der Bruch innerhalb der Distribution, sondern stattdessen der Bruch von privaten Drittanbieter-Skripten, die von Systemadministratoren und anderen Benutzern entwickelt wurden. Die Aktualisierung des Befehls python, um standardmäßig python3 aufzurufen, zeigt, dass eine Distribution bereit ist, solche Skripte mit Fehlern zu brechen, die für Benutzer, die nicht mit den abwärts inkompatiblen Änderungen in Python 3 vertraut sind, potenziell sehr verwirrend sind. Beispielsweise ist zwar die Änderung von print von einer Anweisung zu einer eingebauten Funktion für automatische Konverter relativ einfach zu handhaben, aber der SyntaxError beim Versuch, die Python 2-Notation in Python 3 zu verwenden, kann für Benutzer, die sich der Änderung nicht bewusst sind, verwirrend sein.

  $ python3 -c 'print "Hello, world!"'
    File "<string>", line 1
      print "Hello, world!"
            ^
  SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Hello, world!")?
  

  Auch wenn dies für erfahrene Python-Kenner offensichtlich sein mag, könnten solche Skripte sogar von Leuten ausgeführt werden, die mit Python überhaupt nicht vertraut sind. Die Vermeidung von Brüchen bei solchen Drittanbieter-Skripten war der Hauptgrund, warum dieser PEP früher empfahl, dass python weiterhin auf python2 verweisen sollte.

• Die Fehlermeldung python: command not found ist überraschend gut handhabbar, selbst für Personen, die mit Python nicht vertraut sind.
• Die Befehle pythonX.X (z. B. python3.6) existieren auf modernen Systemen und rufen spezifische Nebenversionen des Python-Interpreters auf. Es kann für distributionsspezifische Pakete nützlich sein, diese Dienstprogramme zu nutzen, wenn sie existieren, da dies Codebrüche vermeidet, wenn die Standard-Nebenversion einer bestimmten Hauptversion geändert wird. Skripte, die plattformübergreifend sein sollen, sollten sich jedoch nicht auf die Verfügbarkeit dieser Dienstprogramme verlassen, sondern auf mehreren aktuellen Nebenversionen der Zielhauptversion getestet werden und gegebenenfalls für die geringfügigen Unterschiede zwischen Nebenversionen kompensieren. Dies vermeidet die Notwendigkeit für Systemadministratoren, viele sehr ähnliche Versionen des Interpreters zu installieren.
• Wenn die pythonX.X-Binärdateien von einer Distribution bereitgestellt werden, sollten die Befehle python2 und python3 auf eine dieser Dateien verweisen, anstatt als separate Binärdatei bereitgestellt zu werden.
• Es wird dringend empfohlen, dass distributionsspezifische Pakete python3 (oder python2) anstelle von python verwenden, auch in Code, der nicht für andere Distributionen bestimmt ist. Dies reduziert Probleme, wenn die Distribution später beschließt, die Version des Python-Interpreters zu ändern, die der Befehl python aufruft, oder wenn ein Systemadministrator einen benutzerdefinierten python-Befehl mit einer anderen Hauptversion als dem Distributionsstandard installiert.
• Wenn der obige Punkt eingehalten wird und Systemadministratoren der Befehl python geändert werden darf, dann sollte der Befehl python immer als Link zur Interpreter-Binärdatei (oder als Link zu einem Link) implementiert werden und nicht umgekehrt. Auf diese Weise können Systemadministratoren, wenn sie sich entscheiden, die installierte python-Datei zu ersetzen, dies tun, ohne versehentlich die zuvor installierte Binärdatei zu löschen.
• Auch wenn der Python 2-Interpreter immer seltener wird, ist es weiterhin sinnvoll, dass Skripte die Konvention python3 anstelle von nur python verwenden.
• Wenn diese Konventionen eingehalten werden, wird der Befehl python nur interaktiv als Benutzerkomfort oder bei Verwendung einer virtuellen Umgebung oder eines ähnlichen Mechanismus ausgeführt.

Abwärtskompatibilität

Ein potenzielles Problem kann auftreten, wenn ein Skript, das sich an die Konvention python2/python3 hält, auf einem System ausgeführt wird, das diese Befehle nicht unterstützt. Dies ist weitgehend kein Problem, da der Systemadministrator diese symbolischen Links einfach erstellen und weitere Probleme vermeiden kann. Es ist ein wesentlich offensichtlicheres Problem als die manchmal kryptischen Fehler, die auftreten können, wenn versucht wird, ein Skript mit Python 2-spezifischer Syntax mit einem Python 3-Interpreter oder umgekehrt auszuführen.

Anwendung auf den CPython-Referenzinterpreter

Obwohl technisch eine neue Funktion, wurden die Befehle make install und make bininstall in der 2.7-Version von CPython angepasst, um die folgenden Ketten von symbolischen Links im entsprechenden bin-Verzeichnis zu erstellen (das letzte Element in der Kette ist die tatsächlich installierte Binärdatei, vorhergehende Elemente sind relative symbolische Links)

python -> python2 -> python2.7
python-config -> python2-config -> python2.7-config

Ähnliche Anpassungen wurden am macOS-Binärinstallationsprogramm vorgenommen.

Diese Funktion erschien erstmals im Standardinstallationsprozess in CPython 2.7.3.

Die Installationsbefehle in der CPython 3.x-Serie erstellen bereits die entsprechenden Symlinks. Zum Beispiel erstellt CPython 3.2

python3 -> python3.2
idle3 -> idle3.2
pydoc3 -> pydoc3.2
python3-config -> python3.2-config

Und CPython 3.3 erstellt

python3 -> python3.3
idle3 -> idle3.3
pydoc3 -> pydoc3.3
python3-config -> python3.3-config
pysetup3 -> pysetup3.3

Die Implementierungsfortschritte dieser Funktionen in den Standardinstallern wurden im Tracker unter Issue #12627 ([3]) verwaltet.

Auswirkungen auf PYTHON*-Umgebungsvariablen

Die Wahl des Ziels für den Befehl python beeinflusst implizit die erwartete Interpretation der verschiedenen Python-bezogenen Umgebungsvariablen durch eine Distribution. Die Verwendung von *.pth-Dateien im entsprechenden site-packages-Ordner, die Funktion „per-user site packages“ (siehe python -m site) oder flexiblere Werkzeuge wie virtualenv sind alle toleranter gegenüber der Anwesenheit mehrerer Python-Versionen auf einem System als die direkte Verwendung von PYTHONPATH.

Ausschluss von MS Windows

Dieser PEP schließt bewusst alle Vorschläge im Zusammenhang mit Microsoft Windows aus, da die Entwicklung einer gleichwertigen Lösung für Windows hier als zu komplex erachtet wurde. PEP 397 und die zugehörige Diskussion auf der python-dev-Mailingliste behandeln dieses Problem.

Referenzen

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.