4. Python unter Windows verwenden

Dieses Dokument gibt einen Überblick über das Windows-spezifische Verhalten, das du kennen solltest, wenn du Python unter Microsoft Windows verwendest.

Anders als die meisten Unix-Systeme und -Dienste bringt Windows keine systemseitig unterstützte Installation von Python mit. Python ist stattdessen von verschiedenen Distributoren zu beziehen, unter anderem direkt vom CPython-Team. Jede Python-Distribution hat ihre eigenen Vor- und Nachteile. Die Übereinstimmung mit den anderen Werkzeugen, die du einsetzt, ist allerdings meist ein Vorteil, der sich lohnt. Bevor du dich auf das hier beschriebene Vorgehen festlegst, empfehlen wir zu prüfen, ob deine vorhandenen Werkzeuge Python nicht direkt bereitstellen können.

Um Python vom CPython-Team zu beziehen, verwende den Python Install Manager. Das ist ein eigenständiges Werkzeug, das Python auf deinem Windows-Rechner als globale Befehle verfügbar macht, sich in das System einfügt und Aktualisierungen über die Zeit unterstützt. Den Python Install Manager kannst du von python.org/downloads oder über die Microsoft Store app herunterladen.

Sobald der Python Install Manager installiert ist, lässt sich der globale Befehl python in jedem Terminal verwenden, um deine derzeit neueste Python-Version zu starten. Diese Version kann sich im Laufe der Zeit ändern, wenn du Versionen hinzufügst oder entfernst. Der Befehl py list zeigt an, welche gerade aktuell ist.

Grundsätzlich empfehlen wir, für jedes Projekt eine virtuelle Umgebung anzulegen und sie mit <env>\Scripts\Activate im Terminal zu aktivieren. Das trennt Projekte voneinander, sorgt für Beständigkeit über die Zeit und stellt sicher, dass zusätzliche Befehle, die Pakete mitbringen, in deiner Sitzung ebenfalls verfügbar sind. Eine virtuelle Umgebung legst du mit python -m venv <env path> an.

Wenn die Befehle python oder py nicht zu funktionieren scheinen, sieh dir den Abschnitt Fehlersuche weiter unten an. Manchmal sind zusätzliche Handgriffe nötig, um deinen PC einzurichten.

Neben dem Python Install Manager ist Python auch als NuGet-Paket zu beziehen. Mehr über diese Pakete steht unter Die Pakete von nuget.org weiter unten.

Die einbettbaren Distributionen sind minimale Python-Pakete, die sich zum Einbetten in größere Anwendungen eignen. Sie lassen sich mit dem Python Install Manager installieren. Mehr über diese Pakete steht unter Das einbettbare Paket weiter unten.

4.1. Python Install Manager

4.1.1. Installation

Der Python Install Manager lässt sich aus der Microsoft Store app installieren oder von python.org/downloads herunterladen und installieren. Die beiden Fassungen sind identisch.

Für die Installation über den Store genügt ein Klick auf „Installieren“. Öffne danach ein Terminal und gib python ein, um loszulegen.

Die von python.org heruntergeladene Datei installierst du entweder per Doppelklick und Auswahl von „Installieren“ oder mit Add-AppxPackage <path to MSIX> in der Windows PowerShell.

Nach der Installation sollten die Befehle python, py und pymanager verfügbar sein. Wenn es bereits Python-Installationen gibt oder du deine Variable PATH verändert hast, musst du sie möglicherweise entfernen beziehungsweise die Änderungen zurücknehmen. Unter Fehlersuche findest du weitere Hilfe, wenn Befehle nicht funktionieren.

Wenn du die erste Runtime installierst, wirst du wahrscheinlich aufgefordert, ein Verzeichnis zu PATH hinzuzufügen. Das ist freiwillig, sofern du lieber den Befehl py verwendest, wird aber jenen angeboten, die die ganze Reihe der Aliasnamen (etwa python3.14.exe) zur Verfügung haben möchten. Das Verzeichnis ist standardmäßig %LocalAppData%\Python\bin, kann aber administrativ angepasst werden. Klicke auf Start und suche nach „Umgebungsvariablen für dieses Konto bearbeiten“, um zu der Systemeinstellungsseite zu kommen, auf der du den Pfad hinzufügst.

Jede installierte Python-Runtime hat ihr eigenes Verzeichnis für Skripte. Auch diese müssen zu PATH hinzugefügt werden, wenn du sie verwenden möchtest.

Der Python Install Manager wird automatisch auf neue Veröffentlichungen aktualisiert. Installierte Python-Runtimes sind davon nicht betroffen. Wird der Python Install Manager deinstalliert, bleiben die Python-Runtimes erhalten.

Wenn sich in deiner Umgebung kein MSIX installieren lässt — etwa weil deine automatisierte Bereitstellungssoftware das nicht unterstützt oder weil Windows Server 2019 das Ziel ist —, findest du unter Fortgeschrittene Installation weiter unten mehr dazu.

4.1.2. Grundlegende Verwendung

Der empfohlene Befehl zum Starten von Python ist python. Er startet entweder die Version, die das aufgerufene Skript verlangt, eine aktive virtuelle Umgebung oder die standardmäßig installierte Version — das ist die neueste stabile Veröffentlichung, sofern nichts anderes eingestellt ist. Wird keine Version ausdrücklich verlangt und ist überhaupt keine Runtime installiert, wird die derzeit neueste Veröffentlichung automatisch installiert.

Für alle Fälle mit mehreren Runtime-Versionen ist py der empfohlene Befehl. Er lässt sich überall anstelle von python oder des älteren Starters py.exe verwenden. Standardmäßig verhält sich py wie python, erlaubt aber zusätzlich Befehlszeilenoptionen zur Auswahl einer bestimmten Version sowie Unterbefehle zur Verwaltung der Installationen. Beides ist weiter unten beschrieben.

Weil der Befehl py schon von der vorherigen Version belegt sein kann, gibt es außerdem den eindeutigen Befehl pymanager. Skriptgesteuerte Installationen, die den Python Install Manager verwenden sollen, sollten pymanager in Betracht ziehen, weil ein Zusammenstoß mit vorhandenen Installationen dort unwahrscheinlicher ist. Die beiden Befehle unterscheiden sich nur beim Aufruf ohne Argumente: py startet deinen Standard-Interpreter, pymanager zeigt die Hilfe an (pymanager exec ... verhält sich wie py ...).

Zu jedem dieser Befehle gibt es auch eine Fenster-Variante, die kein Konsolenfenster erzeugt: pyw, pythonw und pywmanager. Enthalten ist außerdem ein Befehl python3, der den Befehl python nachahmt. Er soll versehentliche Verwendungen des üblichen POSIX-Befehls unter Windows abfangen, ist aber nicht für den breiten Einsatz gedacht und wird nicht empfohlen.

Um deine Standard-Runtime zu starten, rufe python oder py mit den Argumenten auf, die an die Runtime weitergegeben werden sollen (etwa Skriptdateien oder das zu startende Modul):

$> py
...
$> python my-script.py
...
$> py -m this
...

Die Standard-Runtime lässt sich über die Umgebungsvariable PYTHON_MANAGER_DEFAULT oder eine Konfigurationsdatei überschreiben. Unter Konfiguration steht mehr zu den Konfigurationseinstellungen.

Um eine bestimmte Runtime zu starten, nimmt der Befehl py die Option -V:<TAG> an. Diese Option muss vor allen anderen angegeben werden. Das Tag ist ein Teil der Kennung der Runtime oder die ganze Kennung. Bei denen vom CPython-Team sieht es wie die Version aus, möglicherweise mit der Plattform. Aus Gründen der Kompatibilität darf V: entfallen, wenn das Tag auf eine offizielle Veröffentlichung verweist und mit 3 beginnt.

$> py -V:3.14 ...
$> py -V:3-arm64 ...

Bei Runtimes anderer Distributoren muss möglicherweise auch die Company angegeben werden. Sie wird vom Tag durch einen Schrägstrich getrennt (entweder / oder \) und darf auf ein beliebiges Präfix ihres vollen Werts verkürzt werden. Die Angabe der Company ist freiwillig, wenn sie PythonCore lautet, und die Angabe des Tags ist freiwillig (nicht aber die des Schrägstrichs), wenn du die neueste Veröffentlichung einer bestimmten Company möchtest.

$> py -V:Distributor\1.0 ...
$> py -V:distrib/ ...

Wird keine Version angegeben, aber eine Skriptdatei übergeben, wird das Skript auf eine Shebang-Zeile geprüft. Das ist ein besonderes Format für die erste Zeile einer Datei, mit dem sich der Befehl überschreiben lässt. Mehr dazu steht unter Shebang-Zeilen. Gibt es keine Shebang-Zeile oder lässt sie sich nicht auflösen, wird das Skript mit der Standard-Runtime gestartet.

Wenn du in einer aktiven virtuellen Umgebung arbeitest, keine bestimmte Version verlangt hast und keine Shebang-Zeile vorhanden ist, ist diese virtuelle Umgebung die Standard-Runtime. In diesem Fall war der Befehl python ohnehin schon überschrieben und keine dieser Prüfungen hat stattgefunden. Dieses Verhalten stellt aber sicher, dass der Befehl py gleichwertig verwendet werden kann.

Solange keine Runtimes installiert sind, versucht jeder Startbefehl, die verlangte Version zu installieren und zu starten. Sobald irgendeine Version installiert ist, installieren jedoch nur noch die Befehle py exec ... und pymanager exec ... eine fehlende Version. Andere Befehlsformen zeigen einen Fehler an und verweisen dich auf py install.

4.1.3. Hilfe zu den Befehlen

Der Befehl py help zeigt die vollständige Liste der unterstützten Befehle samt ihrer Optionen an. Jedem Befehl lässt sich die Option -? übergeben, um seine Hilfe anzuzeigen, oder sein Name an py help.

$> py help
$> py help install
$> py install /?

Alle Befehle unterstützen einige gemeinsame Optionen, die py help anzeigt. Diese Optionen müssen nach dem jeweiligen Unterbefehl angegeben werden. Mit -v oder --verbose wird mehr ausgegeben, mit -vv zu Zwecken der Fehlersuche noch mehr. Mit -q oder --quiet wird weniger ausgegeben, mit -qq noch weniger.

Mit der Option --config=<PATH> lässt sich eine Konfigurationsdatei angeben, die mehrere Einstellungen auf einmal überschreibt. Mehr über diese Dateien steht unter Konfiguration weiter unten.

4.1.4. Runtimes auflisten

$> py list [-f=|--format=<FMT>] [-1|--one] [--online|-s=|--source=<URL>] [<TAG>...]

Die Liste der installierten Runtimes zeigt py list. Als Filter lassen sich ein oder mehrere Tags angeben (mit oder ohne Company-Angabe), und jedes darf ein Präfix <, <=, >= oder > tragen, um auf einen Bereich einzuschränken.

Es werden mehrere Formate unterstützt, die sich mit der Option --format=<FMT> oder -f <FMT> übergeben lassen. Zur Auswahl stehen table (eine gut lesbare Tabellenansicht), csv (kommagetrennte Tabelle), json (ein einzelner JSON-Block), jsonl (ein JSON-Block je Ergebnis), exe (nur der Pfad zur ausführbaren Datei) und prefix (nur der Präfixpfad).

Die Option --one beziehungsweise -1 zeigt nur ein einzelnes Ergebnis an. Ist die Standard-Runtime darunter, wird sie es sein. Andernfalls wird das „beste“ Ergebnis gezeigt („beste“ ist absichtlich unscharf festgelegt, meint aber meist die neueste Version). Das von py list --one <TAG> gezeigte Ergebnis entspricht der Runtime, die py -V:<TAG> starten würde.

Die Option --only-managed schließt Ergebnisse aus, die nicht vom Python Install Manager installiert wurden. Das ist nützlich, um festzustellen, welche Runtimes sich über den Befehl py aktualisieren oder deinstallieren lassen.

Die Option --online ist die Kurzform für --source=<URL> mit der Standardquelle. Mit einer dieser Optionen wird der Online-Index nach Runtimes durchsucht, die sich installieren lassen. Das von py list --online --one <TAG> gezeigte Ergebnis entspricht der Runtime, die py install <TAG> installieren würde.

$> py list --online 3.14

Aus Gründen der Kompatibilität mit dem alten Starter bleiben die Befehle --list, --list-paths, -0 und -0p (etwa py -0p) erhalten. Sie erlauben keine zusätzlichen Optionen und erzeugen eine Ausgabe im alten Format.

4.1.5. Runtimes installieren

$> py install [-s=|--source=<URL>] [-f|--force] [-u|--update] [--dry-run] [<TAG>...]

Neue Runtime-Versionen lassen sich mit py install hinzufügen. Es können ein oder mehrere Tags angegeben werden, und mit dem besonderen Tag default lässt sich die Standardversion auswählen. Bereiche werden bei der Installation nicht unterstützt.

Mit der Option --source=<URL> lässt sich der Online-Index überschreiben, aus dem die Runtimes bezogen werden. Das kann mit einem Offline-Index verwendet werden, wie unter Offline-Installationen gezeigt.

Mit --force werden zwischengespeicherte Dateien ignoriert und eine vorhandene Installation entfernt, um sie durch die angegebene zu ersetzen.

Passing --update will replace existing installs if the new version is newer. Otherwise, they will be left. If no tags are provided with --update, all installs managed by the Python install manager will be updated if newer versions are available. Updates will remove any modifications made to the install, including globally installed packages, but will leave site-packages and Scripts directories as is. Virtual environments are also unaffected.

Mit --dry-run werden Ausgaben und Protokolle erzeugt, aber keine Installationen verändert.

Mit --refresh werden alle Registrierungen der installierten Runtimes aktualisiert. Dabei werden Startmenü-Verknüpfungen, Registrierungsschlüssel und globale Aliasnamen (etwa python3.14.exe oder solche für installierte Skripte) neu erzeugt. Bei der Installation einer Runtime geschieht das automatisch, nach dem Installieren von Paketen kann es aber nötig sein, es von Hand anzustoßen.

Zusätzlich zu den obigen Optionen entpackt die Option --target die Runtime in das angegebene Verzeichnis, anstatt sie normal zu installieren. Das ist nützlich, um Runtimes in größere Anwendungen einzubetten. Anders als bei einer normalen Installation weiß py nichts von der entpackten Runtime, und es werden keine Startmenü- oder anderen Verknüpfungen angelegt. Um die Runtime zu starten, führe die Hauptdatei (üblicherweise python.exe) im Zielverzeichnis direkt aus.

$> py install ... [-t=|--target=<PATH>] <TAG>

Der Befehl py exec installiert die verlangte Runtime, wenn sie noch nicht vorhanden ist. Gesteuert wird das über die Konfiguration automatic_install (PYTHON_MANAGER_AUTOMATIC_INSTALL), die standardmäßig eingeschaltet ist. Ist überhaupt keine Runtime verfügbar, führen alle Startbefehle eine automatische Installation durch, sofern die Einstellung es erlaubt. Das soll Neueinsteigern einen guten Einstieg verschaffen, man sollte sich aber grundsätzlich nicht darauf verlassen, sondern den Befehl py exec oder ausdrückliche Installationsbefehle verwenden.

4.1.6. Offline-Installationen

Um Python offline zu installieren, musst du zunächst auf einem Rechner mit Netzzugang einen Offline-Index anlegen.

$> py install --download=<PATH> ... <TAG>...

Die Option --download=<PATH> lädt die Pakete für die aufgeführten Tags herunter und legt ein Verzeichnis an, das sie samt einer Datei index.json für die spätere Installation enthält. Dieses ganze Verzeichnis lässt sich auf den Rechner ohne Netzzugang übertragen und dort verwenden, um eine oder mehrere der mitgelieferten Runtimes zu installieren:

$> py install --source="<PATH>\index.json" <TAG>...

Der Python Install Manager lässt sich installieren, indem du sein Installationsprogramm herunterlädst und vor der Installation auf einen anderen Rechner überträgst.

Alternativ lassen sich die ZIP-Dateien in einem Offline-Index-Verzeichnis einfach auf einen anderen Rechner übertragen und dort entpacken. Dabei wird die Installation nicht registriert, sie muss also über die ausführbaren Dateien im entpackten Verzeichnis direkt gestartet werden. Manchmal ist dieses Vorgehen aber vorzuziehen, etwa wenn sich der Python Install Manager nicht installieren lässt oder das unpraktisch ist.

So lassen sich Python-Runtimes auf einem Rechner ohne Internetzugang installieren und verwalten.

4.1.7. Runtimes deinstallieren

$> py uninstall [-y|--yes] <TAG>...

Runtimes lassen sich mit dem Befehl py uninstall entfernen. Dabei müssen ein oder mehrere Tags angegeben werden. Bereiche werden hier nicht unterstützt.

Die Option --yes übergeht die Bestätigungsabfrage vor dem Deinstallieren.

Anstatt Tags einzeln anzugeben, lässt sich die Option --purge verwenden. Sie entfernt alle vom Python Install Manager verwalteten Runtimes und räumt dabei auch Startmenü, Registrierung und etwaige Download-Zwischenspeicher auf. Runtimes, die nicht vom Python Install Manager installiert wurden, bleiben unberührt, ebenso von Hand angelegte Konfigurationsdateien.

$> py uninstall [-y|--yes] --purge

Der Python Install Manager lässt sich über die Windows-Einstellungsseite „Installierte Apps“ deinstallieren. Dabei werden keine Runtimes entfernt, sie bleiben weiterhin verwendbar — die globalen Befehle python und py verschwinden allerdings. Wird der Python Install Manager erneut installiert, kannst du diese Runtimes wieder verwalten. Um alle Python-Runtimes vollständig aufzuräumen, rufe vor dem Deinstallieren des Python Install Managers --purge auf.

4.1.8. Konfiguration

Der Python Install Manager wird über eine Rangfolge aus Konfigurationsdateien, Umgebungsvariablen, Befehlszeilenoptionen und Registrierungseinstellungen konfiguriert. Grundsätzlich können Konfigurationsdateien alles einstellen, auch den Ort anderer Konfigurationsdateien, während Registrierungseinstellungen nur der Administration offenstehen und Konfigurationsdateien überschreiben. Befehlszeilenoptionen überschreiben alle anderen Einstellungen, es ist aber nicht jede Option verfügbar.

Dieser Abschnitt beschreibt die Vorgabewerte. Bedenke aber, dass veränderte oder überschriebene Installationen Einstellungen anders auflösen können.

A global configuration file may be configured by an administrator and would be read first. The user configuration file is stored at %AppData%\Python\pymanager.json (note that this location is under Roaming, not Local) and is read next, overwriting any settings from earlier files. An additional configuration file may be specified as the PYTHON_MANAGER_CONFIG environment variable or the --config command line option (but not both). These locations may be modified by administrative customization options listed later.

Die folgenden Einstellungen gelten als solche, die im normalen Betrieb wahrscheinlich verändert werden. Spätere Abschnitte führen jene auf, die für administrative Anpassungen gedacht sind.

Übliche Konfigurationsoptionen

Konfigurationsschlüssel	Umgebungsvariable	Beschreibung
default_tag	PYTHON_MANAGER_DEFAULT	Die bevorzugte Standardversion zum Starten oder Installieren. Standardmäßig wird darunter die neueste Version des CPython-Teams verstanden, die keine Vorabversion ist.
default_platform	PYTHON_MANAGER_DEFAULT_PLATFORM	Die bevorzugte Standardplattform zum Starten oder Installieren. Sie wird als Suffix zum angegebenen Tag behandelt, sodass py -V:3.14 eine Installation für 3.14-64 bevorzugen würde, falls sie vorhanden ist (und default_platform den Wert -64 hat), aber 3.14 verwendet, wenn es keine so gekennzeichnete Installation gibt.
logs_dir	PYTHON_MANAGER_LOGS	Der Ort, an den Protokolldateien geschrieben werden. Standardmäßig %TEMP%.
automatic_install	PYTHON_MANAGER_AUTOMATIC_INSTALL	True, um automatische Installationen beim Starten über py exec zu erlauben (oder über py, solange noch keine Runtimes installiert sind). Andere Befehle installieren unabhängig von dieser Einstellung nicht automatisch. Standardmäßig true.
include_unmanaged	PYTHON_MANAGER_INCLUDE_UNMANAGED	True, um Runtimes aufzulisten und zu starten, die nicht vom Python Install Manager installiert wurden, oder false, um sie auszuschließen. Standardmäßig true.
shebang_can_run_anything	PYTHON_MANAGER_SHEBANG_CAN_RUN_ANYTHING	True, um Shebangs in .py-Dateien auch andere Anwendungen als Python-Runtimes starten zu lassen, oder false, um das zu verhindern. Standardmäßig true.
shebang_templates	(keine)	Zuordnung von einer Shebang-Zeilen-Vorlage zu einem anderen Befehl, etwa py -V:<tag>, oder zu einer Ersetzungszeichenkette. Mehr dazu unter Shebang-Zeilen.
log_level	PYMANAGER_VERBOSE, PYMANAGER_DEBUG	Legt die Vorgabestufe der Ausgabe fest (0-50). Standardmäßig 20. Niedrigere Werte erzeugen mehr Ausgabe. Die Umgebungsvariablen sind boolesch und können während des Starts zusätzliche Ausgaben erzeugen, die später von anderen Konfigurationen unterdrückt werden.
confirm	PYTHON_MANAGER_CONFIRM	True, um bestimmte Aktionen (etwa das Deinstallieren) vor der Ausführung zu bestätigen, oder false, um die Bestätigung zu überspringen. Standardmäßig true.
install.source	PYTHON_MANAGER_SOURCE_URL	Überschreibt den Index-Feed, von dem neue Installationen bezogen werden.
install.enable_entrypoints	(keine)	True, um globale Befehle für installierte Pakete zu erzeugen (etwa pip.exe). Diese werden von den Paketen selbst festgelegt. Steht die Einstellung auf false, werden globale Befehle nur für den Python-Interpreter angelegt. Standardmäßig true. Nach einer Änderung dieser Einstellung solltest du py install --refresh ausführen.
list.format	PYTHON_MANAGER_LIST_FORMAT	Legt das Standardformat des Befehls py list fest. Standardmäßig table.
install_dir	(keine)	Legt das Wurzelverzeichnis fest, in das Runtimes installiert werden. Wenn du diese Einstellung änderst, sind zuvor installierte Runtimes nicht mehr verwendbar, sofern du sie nicht an den neuen Ort verschiebst.
global_dir	(keine)	Legt das Verzeichnis fest, in dem globale Befehle (etwa python3.14.exe und pip.exe) abgelegt werden. Dieses Verzeichnis sollte zu deinem PATH hinzugefügt werden, damit die Befehle im Terminal verfügbar sind.
download_dir	(keine)	Legt das Verzeichnis fest, in dem heruntergeladene Dateien abgelegt werden. Dieses Verzeichnis ist ein vorübergehender Zwischenspeicher und kann von Zeit zu Zeit aufgeräumt werden.

Namen mit Punkten gehören verschachtelt in JSON-Objekte, list.format wird also als {"list": {"format": "table"}} angegeben.

4.1.9. Shebang-Zeilen

Beginnt die erste Zeile einer Skriptdatei mit #!, spricht man von einer „Shebang“-Zeile. Linux und andere unixartige Betriebssysteme unterstützen solche Zeilen von Haus aus, und dort werden sie häufig verwendet, um anzugeben, wie ein Skript ausgeführt werden soll. Die Befehle python und py erlauben dasselbe für Python-Skripte unter Windows.

Damit Shebang-Zeilen in Python-Skripten zwischen Unix und Windows übertragbar bleiben, werden mehrere „virtuelle“ Befehle unterstützt, mit denen sich der zu verwendende Interpreter angeben lässt. Die unterstützten virtuellen Befehle sind:

• /usr/bin/env <ALIAS>

• /usr/bin/env -S <ALIAS>

• /usr/bin/<ALIAS>

• /usr/local/bin/<ALIAS>

• <ALIAS>

Beginnt die erste Zeile deines Skripts zum Beispiel mit

#! /usr/bin/python

Dann wird das Standard-Python oder eine aktive virtuelle Umgebung ermittelt und verwendet. Da viele für Unix geschriebene Python-Skripte diese Zeile schon enthalten, solltest du feststellen, dass sich solche Skripte ohne Änderung mit dem Starter verwenden lassen. Wenn du unter Windows ein neues Skript schreibst, das auch unter Unix nützlich sein soll, solltest du eine der Shebang-Zeilen verwenden, die mit /usr beginnen.

In jedem der obigen virtuellen Befehle lässt sich <ALIAS> durch einen Aliasnamen aus einer installierten Runtime ersetzen. Das heißt, jeder Befehl, der im Verzeichnis der globalen Aliasnamen erzeugt wurde (das du möglicherweise zu deiner Umgebungsvariablen PATH hinzugefügt hast), lässt sich in einem Shebang verwenden, auch wenn er nicht in deinem PATH liegt. So lassen sich Shebangs wie /usr/bin/python3.12 verwenden, um eine bestimmte Runtime auszuwählen.

Sind keine Runtimes installiert oder ist die automatische Installation eingeschaltet, wird die verlangte Runtime bei Bedarf installiert. Unter Konfiguration steht mehr zu den Konfigurationseinstellungen.

Die Shebang-Form /usr/bin/env durchsucht für unbekannte Befehle außerdem die Umgebungsvariable PATH. Das entspricht dem Verhalten des Unix-Programms env, das dieselbe Suche durchführt, bevorzugt aber bekannte Python-Befehle. Bei der Suche nach beliebigen ausführbaren Dateien kann eine Warnung erscheinen. Diese Suche lässt sich über die Konfigurationsoption shebang_can_run_anything abschalten.

Shebang-Zeilen, die auf keines der Muster passen, werden als Windows-Pfade zu ausführbaren Dateien behandelt, die absolut oder relativ zum Verzeichnis der Skriptdatei sind. Das ist eine Bequemlichkeit für Skripte, die nur unter Windows laufen, etwa von einem Installationsprogramm erzeugte, denn dieses Verhalten ist mit unixartigen Shells nicht vereinbar. Diese Pfade dürfen in Anführungszeichen stehen und mehrere Argumente enthalten. Danach werden der Pfad zum Skript und etwaige weitere Argumente angehängt. Diese Funktion lässt sich über die Konfigurationsoption shebang_can_run_anything abschalten.

Seit Version 26.3 des Python Install Managers lassen sich eigene Shebang-Vorlagen in der Konfigurationsdatei ergänzen. Füge dazu das Objekt shebang_templates mit einem Eintrag je Vorlage hinzu (die Zeichenkette, auf die geprüft wird) sowie dem Befehl, der bei einem Treffer verwendet wird. Die meisten Befehle sollten py -V:<tag> (oder pyw) lauten, um eine deiner installierten Runtimes zu starten. Auch die Form py -3.<version> ist erlaubt, ebenso ein einfaches py, um die Standardversion zu starten. Andere Argumente werden nicht unterstützt.

{
    "shebang_templates": {
        "/usr/bin/python": "py",
        "/usr/bin/my_custom_python": "py -V:MyCustomPython/3"
    }
}

Ist der Ersatzbefehl nicht py oder pyw, wird er in den Shebang zurückgeschrieben und die übliche Behandlung läuft weiter. Ist das Starten beliebiger ausführbarer Dateien erlaubt, kannst du mit einem vollständigen Pfad von Python auf jede ausführbare Datei umleiten. Die Vorlage sollte entweder auf die ganze Zeile passen (ohne führende und abschließende Leerzeichen) oder bis zum ersten Leerzeichen in der Shebang-Zeile.

Bemerkung

Das Verhalten von Shebangs im Python Install Manager unterscheidet sich in Feinheiten vom früheren Starter py.exe, und die alten Konfigurationsoptionen gelten nicht mehr. Wenn du ausdrücklich auf das alte Verhalten oder die alte Konfiguration angewiesen bist, empfehlen wir, den legacy launcher zu installieren. Der Befehl py des alten Starters überschreibt standardmäßig den des PyManagers, und du wirst zum Installieren und Deinstallieren die Befehle von pymanager verwenden müssen.

4.1.10. Fortgeschrittene Installation

Für Fälle, in denen sich kein MSIX installieren lässt — etwa auf manchen älteren administrativen Verteilplattformen —, steht auf der Downloadseite von python.org ein MSI bereit. Dieses MSI hat keine Benutzeroberfläche und kann nur rechnerweite Installationen an seinem Standardort in „Programme“ vornehmen. Es versucht, die System-Umgebungsvariable PATH um diesen Installationsort zu ergänzen. Prüfe das aber in deiner Umgebung nach.

Bemerkung

Windows Server 2019 ist die einzige von CPython unterstützte Windows-Version, die MSIX nicht unterstützt. Für Windows Server 2019 solltest du das MSI verwenden.

Beachte, dass das MSI-Paket keine Runtimes mitbringt und sich daher nicht für Installationen in Umgebungen ohne Netzzugang eignet, sofern du nicht zusätzlich einen Offline-Installationsindex anlegst. Unter Offline-Installationen und Administrative Konfiguration steht, wie du mit diesen Fällen umgehst.

Vom MSI installierte Runtimes werden mit denen des MSIX gemeinsam genutzt und gelten ausschließlich je Benutzer. Der Python Install Manager unterstützt keine rechnerweite Installation von Runtimes. Um eine rechnerweite Installation nachzubilden, kannst du als Administrator py install --target=<shared location> verwenden und eigene systemweite Änderungen an PATH, der Registrierung oder dem Startmenü vornehmen.

Ist das MSIX installiert, die Befehle aber nicht über die Umgebungsvariable PATH verfügbar, findest du sie unter %LocalAppData%\Microsoft\WindowsApps\PythonSoftwareFoundation.PythonManager_3847v3x7pw1km oder %LocalAppData%\Microsoft\WindowsApps\PythonSoftwareFoundation.PythonManager_qbz5n2kfra8p0, je nachdem, ob es von python.org oder über den Windows Store installiert wurde. Die ausführbare Datei direkt aus „Programme“ zu starten, ist nicht empfehlenswert.

Um den Python Install Manager programmgesteuert zu installieren, ist WinGet am einfachsten. Es ist in allen unterstützten Windows-Versionen enthalten:

$> winget install 9NQ7512CXL7T -e --accept-package-agreements --disable-interactivity

# Optional die Konfigurationsprüfung ausführen und alle Änderungen annehmen
$> py install --configure -y

Um den Python Install Manager herunterzuladen und auf einem anderen Rechner zu installieren, lädt der folgende WinGet-Befehl die benötigten Dateien aus dem Store in dein Downloads-Verzeichnis (mit -d <location> lässt sich der Zielort anpassen). Dabei entsteht außerdem eine YAML-Datei, die offenbar nicht benötigt wird, denn das heruntergeladene MSIX lässt sich durch Starten oder mit den folgenden Befehlen installieren.

$> winget download 9NQ7512CXL7T -e --skip-license --accept-package-agreements --accept-source-agreements

Um ein MSIX allein mit PowerShell programmgesteuert zu installieren oder zu deinstallieren, empfehlen sich die PowerShell-Cmdlets Add-AppxPackage und Remove-AppxPackage:

$> Add-AppxPackage C:\Downloads\python-manager-25.0.msix
...
$> Get-AppxPackage PythonSoftwareFoundation.PythonManager | Remove-AppxPackage

Die neueste Veröffentlichung lässt sich von Windows herunterladen und installieren, indem du die AppInstaller-Datei an den Befehl Add-AppxPackage übergibst. Dabei wird das MSIX von python.org verwendet, und das ist nur für Fälle empfehlenswert, in denen eine Installation über den Store (von Hand oder mit WinGet) nicht möglich ist.

$> Add-AppxPackage -AppInstallerFile https://www.python.org/ftp/python/pymanager/pymanager.appinstaller

Auch andere Werkzeuge und Programmierschnittstellen lassen sich verwenden, um ein MSIX-Paket für alle Benutzer eines Rechners bereitzustellen, Python betrachtet das aber nicht als unterstützten Fall. Wir empfehlen, einen Blick auf das PowerShell-Cmdlet Add-AppxProvisionedPackage, die native Windows-Klasse PackageManager oder die Dokumentation und Unterstützung deines Bereitstellungswerkzeugs zu werfen.

Unabhängig von der Installationsart müssen Benutzer weiterhin ihre eigenen Python-Kopien installieren, denn es gibt keine Möglichkeit, diese Installationen ohne angemeldeten Benutzer anzustoßen. Beim MSIX steht die neueste Python-Version allen Benutzern ohne Netzzugang zur Installation bereit.

Beachte, dass sich das MSIX aus dem Store und das von der Python-Webseite in Feinheiten unterscheiden und nicht gleichzeitig installiert werden können. Wo möglich, empfehlen wir die obigen WinGet-Befehle, um das Paket aus dem Store herunterzuladen und so das Risiko widersprüchlicher Installationen zu verringern. Es gibt beim Python Install Manager keine Lizenzeinschränkungen, die einer solchen Verwendung des Store-Pakets entgegenstünden.

4.1.11. Administrative Konfiguration

Es gibt eine Reihe von Optionen, die für die Administration nützlich sein können, um die Konfiguration des Python Install Managers zu überschreiben. Damit lassen sich ein lokaler Zwischenspeicher bereitstellen, bestimmte Arten von Verknüpfungen abschalten und mitgelieferte Inhalte überschreiben. Alle obigen Konfigurationsoptionen lassen sich setzen, ebenso die folgenden.

Konfigurationsoptionen lassen sich in der Registrierung überschreiben, indem Werte unter HKEY_LOCAL_MACHINE\Software\Policies\Python\PyManager gesetzt werden, wobei der Wertname dem Konfigurationsschlüssel entspricht und der Werttyp REG_SZ ist. Beachte, dass dieser Schlüssel selbst angepasst werden kann, allerdings nur durch Ändern der Kernkonfigurationsdatei, die mit dem Python Install Manager ausgeliefert wird. Wir empfehlen jedoch, Registrierungswerte nur dafür zu verwenden, base_config auf eine JSON-Datei zu setzen, die alle Überschreibungen enthält. Überschreibungen per Registrierungsschlüssel ersetzen jede andere eingestellte Einstellung, während base_config es Benutzern erlaubt, Einstellungen weiter nach Bedarf anzupassen.

Beachte, dass die meisten Einstellungen mit Umgebungsvariablen diese Variablen nur deshalb unterstützen, weil ihr Vorgabewert die Variable angibt. Überschreibst du sie, funktioniert die Umgebungsvariable nicht mehr, sofern du sie nicht durch eine andere ersetzt. Der Vorgabewert von confirm ist zum Beispiel wörtlich %PYTHON_MANAGER_CONFIRM%, was die Variable beim Laden auflöst. Überschreibst du den Wert mit yes, wird die Umgebungsvariable nicht mehr verwendet. Überschreibst du ihn mit %CONFIRM%, wird stattdessen jene Umgebungsvariable verwendet.

Konfigurationseinstellungen, die Pfade sind, werden relativ zu dem Verzeichnis gelesen, in dem die Konfigurationsdatei liegt, die sie angegeben hat.

Administrative Konfigurationsoptionen

Konfigurationsschlüssel	Beschreibung
base_config	Die Konfigurationsdatei mit der höchsten Priorität. Beachte, dass nur die integrierte Konfigurationsdatei und die Registrierung diese Einstellung ändern können.
user_config	Die zweite zu lesende Konfigurationsdatei.
additional_config	Die dritte zu lesende Konfigurationsdatei.
registry_override_key	Ort in der Registrierung, der auf Überschreibungen geprüft wird. Beachte, dass nur die integrierte Konfigurationsdatei diese Einstellung ändern kann.
bundled_dir	Nur lesbares Verzeichnis mit lokal zwischengespeicherten Dateien.
install.fallback_source	Pfad oder URL zu einem Index, der herangezogen wird, wenn der Hauptindex nicht erreichbar ist.
install.enable_shortcut_kinds	Kommagetrennte Liste der erlaubten Verknüpfungsarten (etwa "pep514,start"). Erlaubte Verknüpfungen können durch disable_shortcut_kinds dennoch abgeschaltet werden.
install.disable_shortcut_kinds	Kommagetrennte Liste der auszuschließenden Verknüpfungsarten (etwa "pep514,start"). Abgeschaltete Verknüpfungen werden durch enable_shortcut_kinds nicht wieder aktiviert.
install.hard_link_entrypoints	True, um für globale Verknüpfungen harte Links zu verwenden und so Speicherplatz zu sparen. Bei false wird jede ausführbare Verknüpfungsdatei stattdessen kopiert. Nach einer Änderung dieser Einstellung musst du py install --refresh --force ausführen, um vorhandene Befehle zu aktualisieren. Standardmäßig true. Das Abschalten kann zur Fehlersuche nötig sein oder auf Systemen, die mit Dateiverknüpfungen Schwierigkeiten haben.
pep514_root	Ort in der Registrierung, aus dem PEP-514-Einträge gelesen und in den sie geschrieben werden. Standardmäßig HKEY_CURRENT_USER\Software\Python.
start_folder	Startmenü-Ordner, in den Verknüpfungen geschrieben werden. Standardmäßig Python. Dieser Pfad ist relativ zum Programme-Ordner des Benutzers.
virtual_env	Pfad zur aktiven virtuellen Umgebung. Standardmäßig %VIRTUAL_ENV%, darf aber leer gesetzt werden, um die Erkennung virtueller Umgebungen abzuschalten.
shebang_can_run_anything_silently	True, um sichtbare Warnungen zu unterdrücken, wenn ein Shebang eine andere Anwendung als eine Python-Runtime startet.
source_settings	Eine Zuordnung von Quell-URL zu Einstellungen, die nur für diesen Index gelten. Enthalten mehrere Konfigurationsdateien diesen Abschnitt, werden URL-Einstellungen ergänzt oder überschrieben, einzelne Einstellungen aber nicht zusammengeführt. Diese Einstellungen dienen derzeit ausschließlich den Index-Signaturen.

4.1.12. Free-Threading-Binärdateien installieren

Added in version 3.13.

Vorgefertigte Distributionen des Free-Threading-Builds lassen sich installieren, indem Tags mit dem Suffix t angegeben werden.

$> py install 3.14t
$> py install 3.14t-arm64
$> py install 3.14t-32

Damit wird wie üblich installiert und registriert. Wenn du keine anderen Runtimes installiert hast, startet python diese. Andernfalls musst du py -V:3.14t ... verwenden oder, wenn du das Verzeichnis der globalen Aliasnamen zu deiner Umgebungsvariablen PATH hinzugefügt hast, die Befehle python3.14t.exe.

4.1.13. Index-Signaturen

Added in version 26.2.

Index-Dateien können signiert werden, damit Manipulationen auffallen. Eine Signatur ist eine Katalogdatei unter derselben URL wie der Index, an deren Dateinamen .cat angehängt ist. Die Katalogdatei sollte den Hash der zugehörigen Index-Datei enthalten und mit einer gültigen Authenticode-Signatur versehen sein. So lässt sich eine Signatur mit den üblichen Werkzeugen (unter Windows) erzeugen, und es darf jedes Zertifikat verwendet werden, solange das Betriebssystem des Clients dessen Zertifizierungsstelle (Wurzel-CA) bereits vertraut.

Index-Signaturen werden nur heruntergeladen und geprüft, wenn der Abschnitt source_settings der lokalen Konfiguration die Index-URL enthält und requires_signature true ist, oder wenn das Index-JSON requires_signature auf true gesetzt hat. Steht die Einstellung in der lokalen Konfiguration — selbst auf false —, werden die Einstellungen im Index ignoriert.

Neben einer gültigen Signatur lassen sich mit den Einstellungen required_root_subject und required_publisher_subject die zulässigen Signaturen anhand der Subject-Felder des Zertifikats weiter einschränken. Jedes in der Konfiguration angegebene Attribut muss mit dem Attribut im Zertifikat übereinstimmen (zusätzliche Attribute im Zertifikat werden ignoriert). Übliche Attribute sind CN= für den Common Name, O= für die Organisationseinheit und C= für das Land des Herausgebers.

Mit der Einstellung required_publisher_eku lässt sich schließlich verlangen, dass dem Herausgeberzertifikat eine bestimmte erweiterte Schlüsselverwendung (Enhanced Key Usage, EKU) zugewiesen wurde. Die EKU 1.3.6.1.5.5.7.3.3 zeigt zum Beispiel an, dass das Zertifikat für die Codesignatur gedacht war (und nicht für die Server- oder Client-Authentifizierung). In Verbindung mit einer bestimmten Wurzel-CA ergibt das eine weitere Möglichkeit, eine rechtmäßige Signatur zu überprüfen.

Dies ist ein Beispiel für einen Abschnitt source_settings aus einer Konfigurationsdatei. In diesem Fall ist der Herausgeber des Feeds eindeutig durch die Verbindung aus der Wurzel „Microsoft Identity Verification“ und der von dieser Wurzel zugewiesenen EKU bestimmt. Die Signatur wäre in diesem Fall unter https://www.python.org/ftp/python/index-windows.json.cat zu finden.

{
  "source_settings": {
    "https://www.python.org/ftp/python/index-windows.json": {
      "requires_signature": true,
      "required_root_subject": "CN=Microsoft Identity Verification Root Certificate Authority 2020",
      "required_publisher_subject": "CN=Python Software Foundation",
      "required_publisher_eku": "1.3.6.1.4.1.311.97.608394634.79987812.305991749.578777327"
    }
  }
}

Dieselben Einstellungen ließen sich stattdessen in der Datei index.json angeben. In diesem Fall fehlen Wurzel und EKU, das heißt, die Signatur muss gültig sein und einen bestimmten Common Name im Zertifikat des Herausgebers tragen, weitere Prüfungen finden aber nicht statt.

{
  "requires_signature": true,
  "required_publisher_subject": "CN=Python Software Foundation",
  "versions": [
    // ...
  ]
}

Werden Einstellungen aus einem Feed verwendet, wird darauf hingewiesen und die Einstellungen erscheinen in der Protokolldatei oder der ausführlichen Ausgabe. Für Feeds, die häufig verwendet werden, empfiehlt es sich, diese Einstellungen in eine lokale Konfigurationsdatei zu übernehmen, damit unbefugte Änderungen am Feed die Überprüfung nicht abschalten können.

Der Ort der Signaturdatei lässt sich weder im Feed noch über eine Konfigurationsdatei überschreiben. Die Administration kann eigene source_settings in einer verbindlichen Konfigurationsdatei bereitstellen (siehe Administrative Konfiguration).

Schlägt die Signaturprüfung fehl, wirst du darauf hingewiesen und gefragt, ob es weitergehen soll. Ist eine Bestätigung von Hand nicht erlaubt — etwa weil --yes angegeben wurde —, wird immer abgebrochen. Um einen Feed mit ungültiger Konfiguration in diesem Fall zu verwenden, musst du eine Konfigurationsdatei bereitstellen, die die Signaturprüfung für diesen Feed abschaltet.

"source_settings": {
  "https://www.example.com/feed-with-invalid-signature.json": {
    "requires_signature": false
  }
}

4.1.14. Proxy-Einstellungen

Added in version 26.4.

Standardmäßig verwendet der Python Install Manager deine systemweiten Proxy-Einstellungen, einschließlich der automatischen Anmeldung. Für die meisten Benutzer verhält er sich damit genauso wie der Browser und andere Anwendungen.

Um die Einstellungen zu überschreiben, verwende die Umgebungsvariablen NO_PROXY, HTTP_PROXY und HTTPS_PROXY. Sie sollten in der Terminalsitzung gesetzt werden, bevor du den Python Install Manager verwendest. Auch andere Anwendungen können diese Variablen verwenden, sei also vorsichtig, bevor du sie global für den ganzen Rechner setzt.

Wird NO_PROXY auf einen beliebigen nichtleeren Wert gesetzt, wird kein Proxy verwendet. Damit umgehst du die Standard-Proxy-Einstellung deines Systems und versuchst, den Index-Server direkt zu erreichen.

Wird HTTPS_PROXY auf eine Zeichenkette wie example.com:8080 gesetzt, wird für alle HTTPS-Verbindungen dieser Proxy-Server verwendet. Beim Standardindex laufen alle Verbindungen über HTTPS, deshalb ist das die übliche Einstellung zum Überschreiben.

Die Variable HTTP_PROXY kann nötig sein, wenn du einen privaten Index-Server verwendest, der keine verschlüsselten Verbindungen nutzt, bei dem aber der Standard-Proxy-Server überschrieben werden muss. Sie hat dasselbe Format wie HTTPS_PROXY.

In beiden Einstellungen lassen sich Anmeldedaten einbetten. Sind in HTTPS_PROXY Anmeldedaten eingebettet, werden sie allerdings anderen Anmeldedaten vorgezogen. Für beide Proxy-Arten wird nur ein Satz Anmeldedaten verwendet.

4.1.15. Fehlersuche

Wenn dein Python Install Manager nicht richtig zu funktionieren scheint, arbeite bitte diese Prüfungen und Abhilfen durch, ob es damit besser wird. Wenn nicht, melde das Problem bitte in unserem Bugtracker und lege alle einschlägigen Protokolldateien bei (sie werden standardmäßig in dein Verzeichnis %TEMP% geschrieben).

Fehlersuche

Symptom	Das kannst du versuchen
python meldet „command not found“ oder öffnet die Store-App, wenn ich es im Terminal eingebe.	Hast du den Python Install Manager installiert?
	Klicke auf Start, öffne „App-Ausführungsaliase verwalten“ und prüfe, ob die Aliase für „Python (default)“ eingeschaltet sind. Sind sie es bereits, schalte sie einmal aus und wieder ein, um den Befehl zu erneuern. Auch die Befehle „Python (default windowed)“ und „Python install manager“ müssen möglicherweise erneuert werden.
	Prüfe, ob die Befehle py und pymanager funktionieren.
	Stelle sicher, dass deine Variable PATH den Eintrag %UserProfile%\AppData\Local\Microsoft\WindowsApps enthält. Das Betriebssystem bringt diesen Eintrag standardmäßig einmal mit, hinter den anderen Benutzerpfaden. Wurde er entfernt, werden die Verknüpfungen nicht gefunden.
py meldet „command not found“, wenn ich es im Terminal eingebe.	Hast du den Python Install Manager installiert?
	Klicke auf Start, öffne „App-Ausführungsaliase verwalten“ und prüfe, ob die Aliase für „Python (default)“ eingeschaltet sind. Sind sie es bereits, schalte sie einmal aus und wieder ein, um den Befehl zu erneuern. Auch die Befehle „Python (default windowed)“ und „Python install manager“ müssen möglicherweise erneuert werden.
	Stelle sicher, dass deine Variable PATH den Eintrag %UserProfile%\AppData\Local\Microsoft\WindowsApps enthält. Das Betriebssystem bringt diesen Eintrag standardmäßig einmal mit, hinter den anderen Benutzerpfaden. Wurde er entfernt, werden die Verknüpfungen nicht gefunden.
py meldet „can’t open file“, wenn ich Befehle im Terminal eingebe.	Das bedeutet meist, dass der alte Starter installiert ist und Vorrang vor dem Python Install Manager hat. Zum Entfernen klicke auf Start, öffne „Installierte Apps“, suche nach „Python launcher“ und deinstalliere ihn.
python startet nicht dieselbe Runtime wie py	Klicke auf Start, öffne „Installierte Apps“, sieh nach vorhandenen Python-Runtimes und entferne sie entweder oder wähle „Ändern“ und schalte die PATH-Optionen ab.
	Klicke auf Start, öffne „App-Ausführungsaliase verwalten“ und prüfe, ob dein Alias python.exe auf „Python (default)“ gesetzt ist.
python und py starten nicht die Runtime, die ich erwarte	Prüfe deine Umgebungsvariable PYTHON_MANAGER_DEFAULT oder die Konfiguration default_tag. Der Befehl py list zeigt deine Standardversion auf Grundlage dieser Einstellungen an.
	Installationen, die der Python Install Manager verwaltet, werden nicht verwalteten Installationen vorgezogen. Verwende py install, um die erwartete Runtime zu installieren, oder stelle dein Standard-Tag ein.
	Vorab- und Versuchsinstallationen, die nicht vom Python Install Manager verwaltet werden, können stabilen Veröffentlichungen vorgezogen werden. Stelle dein Standard-Tag ein oder deinstalliere die Vorabversion und installiere sie mit py install erneut.
pythonw oder pyw starten nicht dieselbe Runtime wie python oder py	Klicke auf Start, öffne „App-Ausführungsaliase verwalten“ und prüfe, ob deine Aliase pythonw.exe und pyw.exe zu den übrigen passen.
pip meldet „command not found“, wenn ich es im Terminal eingebe.	Hast du eine virtuelle Umgebung aktiviert? Führe dazu das Skript .venv\Scripts\activate im Terminal aus.
	Das Paket kann vorhanden sein, ohne dass die erzeugte ausführbare Datei existiert. Wir empfehlen stattdessen den Befehl python -m pip. Wenn du py install --refresh ausführst und sicherstellst, dass das Verzeichnis der globalen Verknüpfungen in PATH liegt (ist es das nicht, wird es in der Ausgabe des Befehls genannt), sollten Befehle wie pip und die anderer installierter Pakete verfügbar sein.
Ich habe ein Paket mit pip installiert, aber sein Befehl wird nicht gefunden.	Hast du eine virtuelle Umgebung aktiviert? Führe dazu das Skript .venv\Scripts\activate im Terminal aus.
	Für neue Pakete legt der Python Install Manager nicht automatisch globale Verknüpfungen an. Ebenso werden die Verknüpfungen deinstallierter Pakete nicht entfernt. Führe py install --refresh aus, um die globalen Verknüpfungen für neu installierte Pakete zu aktualisieren.
Die Eingabe von script-name.py im Terminal öffnet ein neues Fenster.	Das ist eine bekannte Einschränkung des Betriebssystems. Gib entweder py vor dem Skriptnamen an, lege eine Batchdatei mit demselben Namen wie das Skript an, die @py "%~dpn0.py" %* enthält, oder installiere den legacy launcher und wähle ihn als Verknüpfung für Skripte.
Dateien auf ein Skript zu ziehen funktioniert nicht	Das ist eine bekannte Einschränkung des Betriebssystems. Unterstützt wird es vom legacy launcher oder vom Python Install Manager, wenn er aus dem MSI installiert wurde.
Ich habe den Python Install Manager mehrfach installiert.	Es ist möglich, gleichzeitig aus dem Store oder über WinGet, aus dem MSIX auf der Python-Webseite und aus dem MSI zu installieren. Alle sind miteinander verträglich und teilen Konfiguration und Runtimes.
	Im früheren Abschnitt Fortgeschrittene Installation stehen Wege, den Install Manager anders zu deinstallieren als über die übliche Einstellungsseite „Installierte Apps“ (Programme hinzufügen oder entfernen).
Meine alten py.ini-Einstellungen funktionieren nicht mehr.	Der neue Python Install Manager unterstützt diese Konfigurationsdatei und ihre Einstellungen nicht mehr, sie wird daher ignoriert. Unter Konfiguration steht mehr zu den Konfigurationseinstellungen.

4.2. Das einbettbare Paket

Added in version 3.5.

Die einbettbare Distribution ist eine ZIP-Datei mit einer minimalen Python-Umgebung. Sie ist dafür gedacht, Teil einer anderen Anwendung zu sein, und nicht dafür, von Endbenutzern direkt verwendet zu werden.

Um eine einbettbare Distribution zu installieren, empfehlen wir py install mit der Option --target:

$> py install 3.14-embed --target=<directory>

Im entpackten Zustand ist die einbettbare Distribution (fast) vollständig vom System des Benutzers abgeschottet, auch von Umgebungsvariablen, Einstellungen der Systemregistrierung und installierten Paketen. Die Standardbibliothek liegt als vorkompilierte und optimierte .pyc-Dateien in einem ZIP bei, und python3.dll, python313.dll, python.exe sowie pythonw.exe sind alle enthalten. Tcl/tk (samt allem, was darauf aufbaut, etwa Idle), pip und die Python-Dokumentation sind nicht enthalten.

Eine Standarddatei ._pth liegt bei, die die Standardsuchpfade weiter einschränkt (wie unten unter Module finden beschrieben). Diese Datei ist dafür gedacht, von Einbettenden nach Bedarf angepasst zu werden.

Pakete von Dritten sollten vom Installationsprogramm der Anwendung neben der einbettbaren Distribution installiert werden. Abhängigkeiten mit pip zu verwalten wie bei einer gewöhnlichen Python-Installation wird mit dieser Distribution nicht unterstützt, auch wenn es mit einiger Sorgfalt möglich sein mag, pip für automatische Aktualisierungen beizulegen und zu verwenden. Grundsätzlich sollten Pakete von Dritten als Teil der Anwendung behandelt werden („Vendoring“), damit die Entwicklung die Verträglichkeit mit neueren Versionen sicherstellen kann, bevor sie Aktualisierungen an die Benutzer ausliefert.

Die beiden empfohlenen Anwendungsfälle dieser Distribution sind unten beschrieben.

4.2.1. Python-Anwendung

Eine in Python geschriebene Anwendung erfordert nicht zwangsläufig, dass die Benutzer davon wissen. Die einbettbare Distribution lässt sich in diesem Fall verwenden, um eine private Python-Version in ein Installationspaket aufzunehmen. Je nachdem, wie unauffällig das sein soll (oder umgekehrt, wie professionell es wirken soll), gibt es zwei Möglichkeiten.

Eine besondere ausführbare Datei als Starter zu verwenden erfordert etwas Programmierarbeit, bietet den Benutzern aber das unauffälligste Erlebnis. Mit einem eigenen Starter gibt es keine offensichtlichen Anzeichen dafür, dass das Programm auf Python läuft: Symbole lassen sich anpassen, Angaben zu Unternehmen und Version festlegen, und Dateiverknüpfungen verhalten sich richtig. In den meisten Fällen sollte ein eigener Starter einfach Py_Main mit einer festgelegten Befehlszeile aufrufen können.

Der einfachere Weg ist, eine Batchdatei oder eine erzeugte Verknüpfung bereitzustellen, die python.exe oder pythonw.exe direkt mit den nötigen Befehlszeilenargumenten aufruft. In diesem Fall erscheint die Anwendung als Python und nicht unter ihrem eigenen Namen, und Benutzer könnten Schwierigkeiten haben, sie von anderen laufenden Python-Prozessen oder Dateiverknüpfungen zu unterscheiden.

Beim zweiten Weg sollten Pakete als Verzeichnisse neben der ausführbaren Python-Datei installiert werden, damit sie im Suchpfad liegen. Mit dem besonderen Starter können Pakete auch an anderen Orten liegen, weil sich der Suchpfad vor dem Starten der Anwendung festlegen lässt.

4.2.2. Python einbetten

In nativem Code geschriebene Anwendungen brauchen oft eine Skriptsprache, und dafür lässt sich die einbettbare Python-Distribution verwenden. Grundsätzlich liegt der größte Teil der Anwendung in nativem Code, und ein Teil ruft entweder python.exe auf oder verwendet python3.dll direkt. In beiden Fällen genügt es, die einbettbare Distribution in ein Unterverzeichnis der Anwendungsinstallation zu entpacken, um einen ladbaren Python-Interpreter bereitzustellen.

Wie bei der Verwendung als Anwendung können Pakete an jedem Ort installiert werden, weil sich die Suchpfade vor dem Hochfahren des Interpreters festlegen lassen. Davon abgesehen gibt es keine grundlegenden Unterschiede zwischen der einbettbaren Distribution und einer gewöhnlichen Installation.

4.3. Die Pakete von nuget.org

Added in version 3.5.2.

Das Paket von nuget.org ist eine verkleinerte Python-Umgebung, die für Systeme zur fortlaufenden Integration und für Buildsysteme gedacht ist, auf denen Python nicht systemweit installiert ist. Nuget ist zwar „der Paketmanager für .NET“, funktioniert aber auch für Pakete mit Werkzeugen für die Bauzeit einwandfrei.

Die neuesten Hinweise zur Verwendung von nuget stehen auf nuget.org. Es folgt eine Zusammenfassung, die Python-Entwicklern genügt.

Das Befehlszeilenwerkzeug nuget.exe lässt sich direkt von https://dist.nuget.org/win-x86-commandline/latest/nuget.exe herunterladen, zum Beispiel mit curl oder PowerShell. Mit dem Werkzeug wird die neueste Python-Version für 64-Bit- oder 32-Bit-Rechner so installiert:

nuget.exe install python -ExcludeVersion -OutputDirectory .
nuget.exe install pythonx86 -ExcludeVersion -OutputDirectory .

Um eine bestimmte Version auszuwählen, ergänze ein -Version 3.x.y. Das Ausgabeverzeichnis kann von . abweichen, und das Paket wird in ein Unterverzeichnis installiert. Standardmäßig trägt das Unterverzeichnis denselben Namen wie das Paket, und ohne die Option -ExcludeVersion enthält dieser Name die installierte Version. In dem Unterverzeichnis liegt ein Verzeichnis tools mit der Python-Installation:

# Ohne -ExcludeVersion
> .\python.3.5.2\tools\python.exe -V
Python 3.5.2

# Mit -ExcludeVersion
> .\python\tools\python.exe -V
Python 3.5.2

Grundsätzlich lassen sich nuget-Pakete nicht aktualisieren. Neuere Versionen sollten nebeneinander installiert und über den vollständigen Pfad angesprochen werden. Alternativ kannst du das Paketverzeichnis von Hand löschen und es erneut installieren. Viele CI-Systeme tun das automatisch, wenn sie Dateien zwischen Builds nicht aufbewahren.

Neben dem Verzeichnis tools liegt ein Verzeichnis build\native. Es enthält eine MSBuild-Eigenschaftsdatei python.props, die sich in einem C++-Projekt verwenden lässt, um auf die Python-Installation zu verweisen. Werden die Einstellungen eingebunden, verwendet dein Build automatisch die Headerdateien und Importbibliotheken.

Die Paketinformationsseiten auf nuget.org sind www.nuget.org/packages/python für die 64-Bit-Version, www.nuget.org/packages/pythonx86 für die 32-Bit-Version und www.nuget.org/packages/pythonarm64 für die ARM64-Version

4.3.1. Free-Threading-Pakete

Added in version 3.13.

Pakete mit Free-Threading-Binärdateien heißen python-freethreaded für die 64-Bit-Version, pythonx86-freethreaded für die 32-Bit-Version und pythonarm64-freethreaded für die ARM64-Version. Diese Pakete enthalten sowohl den Einsprungpunkt python3.13t.exe als auch python.exe, die beide im Free-Threading-Betrieb laufen.

4.4. Alternative Distributionen

Neben der Standard-Distribution von CPython gibt es abgewandelte Pakete mit zusätzlichen Funktionen. Es folgt eine Liste verbreiteter Varianten und ihrer wichtigsten Eigenschaften:

ActivePython

Installationsprogramm mit plattformübergreifender Verträglichkeit, Dokumentation, PyWin32

Anaconda

Verbreitete wissenschaftliche Module (etwa numpy, scipy und pandas) und der Paketmanager conda.

Enthought Deployment Manager

„The Next Generation Python Environment and Package Manager“.

Früher stellte Enthought Canopy bereit, das aber 2016 das Ende seiner Lebensdauer erreicht hat.

WinPython

Windows-spezifische Distribution mit vorgefertigten wissenschaftlichen Paketen und Werkzeugen zum Bauen von Paketen.

Beachte, dass diese Pakete nicht die neuesten Versionen von Python oder anderen Bibliotheken enthalten müssen und nicht vom Kern-Team von Python gepflegt oder unterstützt werden.

4.5. Unterstützte Windows-Versionen

Wie in PEP 11 festgelegt, unterstützt eine Python-Veröffentlichung eine Windows-Plattform nur so lange, wie Microsoft sie im erweiterten Support führt. Das heißt, Python 3.15 unterstützt Windows 10 und neuer. Wenn du Unterstützung für Windows 7 brauchst, installiere bitte Python 3.8. Brauchst du Unterstützung für Windows 8.1, installiere bitte Python 3.12.

4.6. Die Beschränkung durch MAX_PATH aufheben

Windows hat die Pfadlänge aus historischen Gründen auf 260 Zeichen beschränkt. Längere Pfade ließen sich dadurch nicht auflösen, und es kam zu Fehlern.

In den neuesten Windows-Versionen lässt sich diese Beschränkung auf über 32.000 Zeichen erweitern. Deine Administration muss dazu die Gruppenrichtlinie „Win32-Pfade mit langen Namen aktivieren“ einschalten oder LongPathsEnabled im Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem auf 1 setzen.

Damit können die Funktion open(), das Modul os und die meisten anderen Pfadfunktionen Pfade mit mehr als 260 Zeichen annehmen und zurückgeben.

Nach dem Ändern der obigen Option und einem Neustart ist keine weitere Einrichtung nötig.

4.7. UTF-8-Modus

Added in version 3.7.

Geändert in Version 3.15: Der UTF-8-Modus von Python ist jetzt standardmäßig eingeschaltet (PEP 686).

Windows verwendet für die Systemkodierung weiterhin alte Kodierungen (die ANSI-Codepage). Ist der UTF-8-Modus von Python abgeschaltet, verwendet Python die ANSI-Codepage als Standardkodierung für Textdateien, wie locale.getencoding() sie zurückgibt.

Das kann Schwierigkeiten machen, weil UTF-8 im Internet und auf den meisten Unix-Systemen weit verbreitet ist, auch im WSL (Windows-Subsystem für Linux).

Der standardmäßig eingeschaltete UTF-8-Modus von Python ignoriert die Systemkodierung und verwendet UTF-8 als Standardkodierung für Text. Ist der UTF-8-Modus eingeschaltet, kannst du die Systemkodierung (die ANSI-Codepage) weiterhin über den Codec „mbcs“ verwenden.

Den UTF-8-Modus von Python kannst du über die Befehlszeilenoption -X utf8=0 oder die Umgebungsvariable PYTHONUTF8=0 abschalten. Zum Abschalten des UTF-8-Modus siehe PYTHONUTF8, und unter Python Install Manager steht, wie du Umgebungsvariablen änderst.

Hinweis

Wird PYTHONUTF8={0,1} zu den Standard-Umgebungsvariablen hinzugefügt, betrifft das alle Anwendungen mit Python 3.7 und neuer auf deinem System. Wenn du Anwendungen mit Python 3.7 oder neuer hast, die auf die alte Systemkodierung angewiesen sind, empfiehlt es sich, die Umgebungsvariable nur vorübergehend zu setzen oder die Befehlszeilenoption -X utf8 zu verwenden.

Bemerkung

Auch bei abgeschaltetem UTF-8-Modus verwendet Python unter Windows standardmäßig UTF-8 für:

• Ein- und Ausgabe der Konsole einschließlich der Standard-Ein- und -Ausgabe (Einzelheiten in PEP 528).

• Die Dateisystemkodierung (Einzelheiten in PEP 529).

4.8. Module finden

Diese Hinweise ergänzen die Beschreibung unter The initialization of the sys.path module search path um Einzelheiten zu Windows.

Wird keine Datei ._pth gefunden, wird sys.path unter Windows so gefüllt:

• Am Anfang wird ein leerer Eintrag hinzugefügt, der dem aktuellen Verzeichnis entspricht.

• Existiert die Umgebungsvariable PYTHONPATH, wie unter Umgebungsvariablen beschrieben, werden als nächstes ihre Einträge hinzugefügt. Beachte, dass die Pfade in dieser Variablen unter Windows durch Semikolons getrennt sein müssen, um sie vom Doppelpunkt in Laufwerksbezeichnungen (C:\ und so weiter) zu unterscheiden.

• Weitere „Anwendungspfade“ lassen sich in der Registrierung als Unterschlüssel von \SOFTWARE\Python\PythonCore{version}\PythonPath sowohl unter HKEY_CURRENT_USER als auch unter HKEY_LOCAL_MACHINE hinzufügen. Unterschlüssel, deren Standardwert durch Semikolons getrennte Pfadangaben sind, führen dazu, dass jeder dieser Pfade zu sys.path hinzugefügt wird. (Beachte, dass alle bekannten Installationsprogramme nur HKLM verwenden, HKCU ist daher meist leer.)

• Ist die Umgebungsvariable PYTHONHOME gesetzt, wird sie als „Python-Heimat“ angenommen. Andernfalls wird über den Pfad der ausführbaren Python-Hauptdatei eine „Wegmarke“ gesucht (entweder Lib\os.py oder pythonXY.zip), um die „Python-Heimat“ zu erschließen. Wird eine Python-Heimat gefunden, richten sich die zu sys.path hinzugefügten Unterverzeichnisse (Lib, plat-win und so weiter) nach diesem Ordner. Andernfalls wird der Kernpfad von Python aus dem in der Registrierung gespeicherten PythonPath gebildet.

• Lässt sich die Python-Heimat nicht ermitteln, ist in der Umgebung kein PYTHONPATH angegeben und sind keine Registrierungseinträge zu finden, wird ein Standardpfad mit relativen Einträgen verwendet (etwa .\Lib;.\plat-win und so weiter).

Wird neben der ausführbaren Hauptdatei oder im Verzeichnis eine Ebene darüber eine Datei pyvenv.cfg gefunden, gilt Folgendes abweichend:

• Ist home ein absoluter Pfad und PYTHONHOME nicht gesetzt, wird beim Erschließen der Heimat dieser Pfad anstelle des Pfads zur ausführbaren Hauptdatei verwendet.

Unterm Strich ergibt sich daraus:

• Wird python.exe oder eine andere .exe im Python-Hauptverzeichnis ausgeführt (entweder eine installierte Version oder direkt aus dem Verzeichnis PCbuild), wird der Kernpfad erschlossen und die Kernpfade in der Registrierung werden ignoriert. Andere „Anwendungspfade“ in der Registrierung werden immer gelesen.

• Läuft Python innerhalb einer anderen .exe (anderes Verzeichnis, über COM eingebettet und so weiter), wird die „Python-Heimat“ nicht erschlossen, es wird daher der Kernpfad aus der Registrierung verwendet. Andere „Anwendungspfade“ in der Registrierung werden immer gelesen.

• Findet Python seine Heimat nicht und gibt es keinen Registrierungswert (eingefrorene .exe, sehr eigenartige Installationsaufbauten), erhältst du einen Pfad mit einigen vorgegebenen, aber relativen Pfaden.

Wer Python in seine Anwendung oder Distribution einpacken möchte, vermeidet mit den folgenden Ratschlägen Konflikte mit anderen Installationen:

• Lege eine Datei ._pth neben deine ausführbare Datei, die die einzubeziehenden Verzeichnisse enthält. Damit werden in der Registrierung und in Umgebungsvariablen aufgeführte Pfade ignoriert, ebenso site, sofern dort nicht import site steht.

• Wenn du python3.dll oder python37.dll in deiner eigenen ausführbaren Datei lädst, setze PyConfig.module_search_paths ausdrücklich vor Py_InitializeFromConfig().

• Leere beziehungsweise überschreibe PYTHONPATH und setze PYTHONHOME, bevor du python.exe aus deiner Anwendung startest.

• Wenn du die vorherigen Vorschläge nicht verwenden kannst (etwa weil du eine Distribution bist, die den direkten Aufruf von python.exe erlaubt), stelle sicher, dass die Wegmarke (Lib\os.py) in deinem Installationsverzeichnis vorhanden ist. (Beachte, dass sie innerhalb einer ZIP-Datei nicht erkannt wird, eine richtig benannte ZIP-Datei dagegen schon.)

Damit ist sichergestellt, dass die Dateien einer systemweiten Installation nicht Vorrang vor der mit deiner Anwendung ausgelieferten Standardbibliothek erhalten. Andernfalls könnten deine Benutzer Schwierigkeiten mit deiner Anwendung bekommen. Beachte, dass der erste Vorschlag der beste ist, weil die anderen weiterhin für ungewöhnliche Pfade in der Registrierung und für site-packages des Benutzers anfällig sein können.

Geändert in Version 3.6: Unterstützung für die Datei ._pth hinzugefügt und die Option applocal aus pyvenv.cfg entfernt.

Geändert in Version 3.6: pythonXX.zip als mögliche Wegmarke hinzugefügt, wenn sie direkt neben der ausführbaren Datei liegt.

Veraltet ab Version 3.6: Module, die in der Registrierung unter Modules (nicht PythonPath) angegeben sind, können von importlib.machinery.WindowsRegistryFinder importiert werden. Dieser Finder ist unter Windows in 3.6.0 und früher eingeschaltet, muss künftig aber möglicherweise ausdrücklich zu sys.meta_path hinzugefügt werden.

4.9. Zusätzliche Module

Auch wenn Python darauf abzielt, auf allen Plattformen zu laufen, gibt es Funktionen, die es nur unter Windows gibt. Es existieren einige Module — in der Standardbibliothek und außerhalb — sowie Codeschnipsel, um diese Funktionen zu nutzen.

Die Windows-spezifischen Standardmodule sind unter MS Windows-spezifische Dienste beschrieben.

4.9.1. PyWin32

Das Modul PyWin32 von Mark Hammond ist eine Sammlung von Modulen für fortgeschrittene Windows-spezifische Unterstützung. Dazu gehören Hilfsmittel für:

• Component Object Model (COM)

• Win32-API-Aufrufe

• Registrierung

• Ereignisprotokoll

• Benutzeroberflächen mit Microsoft Foundation Classes (MFC)

PythonWin ist eine Beispielanwendung mit MFC, die mit PyWin32 ausgeliefert wird. Es ist eine einbettbare Entwicklungsumgebung mit integriertem Debugger.

Siehe auch

Win32 How Do I…?

von Tim Golden

Python and COM

von David und Paul Boddie

4.9.2. cx_Freeze

cx_Freeze verpackt Python-Skripte in ausführbare Windows-Programme (*.exe-Dateien). Danach kannst du deine Anwendung weitergeben, ohne dass deine Benutzer Python installieren müssen.

4.10. Python unter Windows kompilieren

Wenn du CPython selbst kompilieren möchtest, besorge dir als Erstes den Quellcode. Du kannst entweder den Quellcode der neuesten Veröffentlichung herunterladen oder einfach einen frischen Checkout holen.

Der Quellbaum enthält eine Build-Solution und Projektdateien für Microsoft Visual Studio, den Compiler, mit dem die offiziellen Python-Veröffentlichungen gebaut werden. Diese Dateien liegen im Verzeichnis PCbuild.

Allgemeine Hinweise zum Bauvorgang stehen in PCbuild/readme.txt.

Für Erweiterungsmodule siehe Building C and C++ Extensions on Windows.

4.11. Das vollständige Installationsprogramm (veraltet)

Veraltet ab Version 3.14: Dieses Installationsprogramm ist seit 3.14 veraltet und wird für Python 3.16 und neuer nicht mehr erstellt. Das aktuelle Installationsprogramm findest du unter Python Install Manager.

4.11.1. Installationsschritte

Für Python 3.15 stehen vier Installationsprogramme zum Herunterladen bereit — jeweils zwei für die 32-Bit- und die 64-Bit-Version des Interpreters. Das Web-Installationsprogramm ist ein kleiner erster Download und lädt die benötigten Bestandteile bei Bedarf automatisch nach. Das Offline-Installationsprogramm enthält die für eine Standardinstallation nötigen Bestandteile und braucht nur für optionale Funktionen eine Internetverbindung. Unter Ohne Herunterladen installieren stehen weitere Wege, das Herunterladen während der Installation zu vermeiden.

Nach dem Starten den Installers kann eine der beiden Optionen ausgewählt werden:

Wenn du „Jetzt installieren“ wählst:

• Du brauchst keine Administratorrechte (es sei denn, eine Systemaktualisierung der C-Laufzeitbibliothek ist nötig oder du installierst den Python Install Manager für alle Benutzer)

• Python wird in dein Benutzerverzeichnis installiert

• Der Python Install Manager wird gemäß der Option am unteren Rand der ersten Seite installiert

• Die Standardbibliothek, die Testsammlung, der Starter und pip werden installiert

• Wenn ausgewählt, wird das Installationsverzeichnis zu deinem PATH hinzugefügt

• Verknüpfungen sind nur für den aktuellen Benutzer sichtbar

Mit „Customize installation“ kannst du die zu installierenden Funktionen, den Installationsort und weitere Optionen oder Aktionen nach der Installation auswählen. Um Debugsymbole oder Debug-Binärdateien zu installieren, brauchst du diese Option.

Für eine Installation für alle Benutzer solltest du „Customize installation“ wählen. In diesem Fall:

• Möglicherweise musst du administrative Anmeldedaten oder eine Freigabe bereitstellen

• Python wird in das Verzeichnis „Programme“ installiert

• Der Python Install Manager wird in das Windows-Verzeichnis installiert

• Optionale Funktionen lassen sich während der Installation auswählen

• Die Standardbibliothek kann vorab zu Bytecode kompiliert werden

• Wenn ausgewählt, wird das Installationsverzeichnis zum System-PATH hinzugefügt

• Verknüpfungen stehen allen Benutzern zur Verfügung

4.11.2. Die Beschränkung durch MAX_PATH aufheben

Windows hat die Pfadlänge aus historischen Gründen auf 260 Zeichen beschränkt. Längere Pfade ließen sich dadurch nicht auflösen, und es kam zu Fehlern.

In den neuesten Windows-Versionen lässt sich diese Beschränkung auf etwa 32.000 Zeichen erweitern. Deine Administration muss dazu die Gruppenrichtlinie „Win32-Pfade mit langen Namen aktivieren“ einschalten oder LongPathsEnabled im Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem auf 1 setzen.

Damit können die Funktion open(), das Modul os und die meisten anderen Pfadfunktionen Pfade mit mehr als 260 Zeichen annehmen und zurückgeben.

Nach dem Ändern der obigen Option ist keine weitere Einrichtung nötig.

Geändert in Version 3.6: Die Unterstützung langer Pfade wurde in Python eingeschaltet.

4.11.3. Ohne Oberfläche installieren

Alle in der Oberfläche des Installationsprogramms verfügbaren Optionen lassen sich auch über die Befehlszeile angeben, sodass skriptgesteuerte Installationen eine Installation ohne Zutun des Benutzers auf vielen Rechnern nachbilden können. Diese Optionen lassen sich auch setzen, ohne die Oberfläche zu unterdrücken, um einige der Vorgaben zu ändern.

Die folgenden Optionen (zu finden, indem das Installationsprogramm mit /? aufgerufen wird) lassen sich an das Installationsprogramm übergeben:

Name	Beschreibung
/passive	zeigt den Fortschritt an, ohne Zutun des Benutzers zu verlangen
/quiet	installiert beziehungsweise deinstalliert, ohne eine Oberfläche anzuzeigen
/simple	verhindert Anpassungen durch den Benutzer
/uninstall	entfernt Python (ohne Bestätigung)
/layout [directory]	lädt alle Bestandteile vorab herunter
/log [filename]	gibt den Ort der Protokolldateien an

Alle anderen Optionen werden als name=value übergeben, wobei der Wert meist 0 zum Abschalten einer Funktion, 1 zum Einschalten einer Funktion oder ein Pfad ist. Die vollständige Liste der verfügbaren Optionen steht unten.

Name	Beschreibung	Standard
InstallAllUsers	Nimmt eine systemweite Installation vor.	0
TargetDir	Das Installations-Verzeichnis	Wird anhand von InstallAllUsers gewählt
DefaultAllUsersTargetDir	Das Standardinstallationsverzeichnis für Installationen für alle Benutzer	%ProgramFiles%\Python X.Y or %ProgramFiles(x86)%\Python X.Y
DefaultJustForMeTargetDir	Das Standardinstallationsverzeichnis für Installationen nur für mich	%LocalAppData%\Programs\Python\PythonXY or %LocalAppData%\Programs\Python\PythonXY-32 or %LocalAppData%\Programs\Python\PythonXY-64
DefaultCustomTargetDir	Das in der Oberfläche angezeigte Standardverzeichnis für eine eigene Installation	(leer)
AssociateFiles	Legt Dateiverknüpfungen an, wenn auch der Starter installiert ist.	1
CompileAll	Kompiliert alle .py-Dateien zu .pyc.	0
PrependPath	Stellt die Installations- und Scripts-Verzeichnisse an den Anfang von PATH und fügt .PY zu PATHEXT hinzu	0
AppendPath	Hängt die Installations- und Scripts-Verzeichnisse an PATH an und fügt .PY zu PATHEXT hinzu	0
Shortcuts	Legt Verknüpfungen für den Interpreter, die Dokumentation und IDLE an, sofern installiert.	1
Include_doc	Installiert das Python-Handbuch	1
Include_debug	Installiert die Debug-Binärdateien	0
Include_dev	Installiert Headerdateien und Bibliotheken für die Entwicklung. Wird das weggelassen, kann die Installation unbrauchbar sein.	1
Include_exe	Installiert python.exe und zugehörige Dateien. Wird das weggelassen, kann die Installation unbrauchbar sein.	1
Include_launcher	Installiert den Python Install Manager.	1
InstallLauncherAllUsers	Installiert den Starter für alle Benutzer. Erfordert außerdem, dass Include_launcher auf 1 gesetzt ist	1
Include_lib	Installiert die Standardbibliothek und die Erweiterungsmodule. Wird das weggelassen, kann die Installation unbrauchbar sein.	1
Include_pip	Installiert die beiliegenden pip und setuptools	1
Include_symbols	Installiert Debugsymbole (*.pdb)	0
Include_tcltk	Installiert die Unterstützung für Tcl/Tk und IDLE	1
Include_test	Installiert die Testsammlung der Standardbibliothek	1
Include_tools	Installiert Hilfsskripte	1
LauncherOnly	Installiert nur den Starter. Das überschreibt die meisten anderen Optionen.	0
SimpleInstall	Schaltet den größten Teil der Installationsoberfläche ab	0
SimpleInstallDescription	Eine eigene Meldung, die bei der vereinfachten Installationsoberfläche angezeigt wird.	(leer)

Um zum Beispiel stillschweigend eine systemweite Standardinstallation von Python vorzunehmen, kannst du den folgenden Befehl verwenden (an einer Eingabeaufforderung mit erhöhten Rechten):

python-3.9.0.exe /quiet InstallAllUsers=1 PrependPath=1 Include_test=0

Damit Benutzer bequem eine eigene Python-Kopie ohne die Testsammlung installieren können, kannst du eine Verknüpfung mit dem folgenden Befehl bereitstellen. Dabei wird eine vereinfachte erste Seite angezeigt und eine Anpassung verhindert:

python-3.9.0.exe InstallAllUsers=0 Include_launcher=0 Include_test=0
    SimpleInstall=1 SimpleInstallDescription="Just for me, no test suite."

(Beachte, dass mit dem Starter auch die Dateiverknüpfungen wegfallen. Das ist nur für Installationen je Benutzer empfehlenswert, wenn es zusätzlich eine systemweite Installation gibt, die den Starter enthielt.)

Die oben aufgeführten Optionen lassen sich auch in einer Datei namens unattend.xml neben der ausführbaren Datei angeben. Diese Datei gibt eine Liste von Optionen und Werten an. Wird ein Wert als Attribut angegeben, wird er nach Möglichkeit in eine Zahl umgewandelt. Als Elementtext angegebene Werte bleiben immer Zeichenketten. Diese Beispieldatei setzt dieselben Optionen wie das vorige Beispiel:

<Options>
    <Option Name="InstallAllUsers" Value="no" />
    <Option Name="Include_launcher" Value="0" />
    <Option Name="Include_test" Value="no" />
    <Option Name="SimpleInstall" Value="yes" />
    <Option Name="SimpleInstallDescription">Just for me, no test suite</Option>
</Options>

4.11.4. Ohne Herunterladen installieren

Da einige Funktionen von Python nicht im ersten Download des Installationsprogramms enthalten sind, kann die Auswahl dieser Funktionen eine Internetverbindung erfordern. Um das zu vermeiden, lassen sich alle möglichen Bestandteile bei Bedarf herunterladen und zu einem vollständigen Layout zusammenstellen, das unabhängig von den gewählten Funktionen keine Internetverbindung mehr braucht. Beachte, dass dieser Download größer sein kann als nötig. Wenn aber viele Installationen vorgenommen werden sollen, ist eine lokal zwischengespeicherte Kopie sehr nützlich.

Führe den folgenden Befehl an der Eingabeaufforderung aus, um alle möglicherweise benötigten Dateien herunterzuladen. Denke daran, python-3.9.0.exe durch den tatsächlichen Namen deines Installationsprogramms zu ersetzen und Layouts in eigenen Verzeichnissen anzulegen, damit Dateien gleichen Namens nicht zusammenstoßen.

python-3.9.0.exe /layout [optional target directory]

Mit der Option /quiet lässt sich außerdem die Fortschrittsanzeige verbergen.

4.11.5. Eine Installation ändern

Nachdem Python installiert ist, kannst du Funktionen über das zu Windows gehörende Werkzeug „Programme und Features“ hinzufügen oder entfernen. Wähle den Python-Eintrag und dann „Deinstallieren/Ändern“, um das Installationsprogramm im Wartungsmodus zu öffnen.

Mit „Modify“ lassen sich Funktionen über die Kontrollkästchen hinzufügen oder entfernen — unveränderte Kästchen installieren und entfernen nichts. Einige Optionen lassen sich in diesem Modus nicht ändern, etwa das Installationsverzeichnis. Dafür musst du Python vollständig entfernen und neu installieren.

Mit „Repair“ werden alle Dateien überprüft, die mit den aktuellen Einstellungen installiert sein sollten, und alle ersetzt, die entfernt oder verändert wurden.

Mit „Uninstall“ wird Python vollständig entfernt, mit Ausnahme des Python Install Manager, der seinen eigenen Eintrag in „Programme und Features“ hat.

4.11.6. Free-Threading-Binärdateien installieren

Added in version 3.13.

Um vorgefertigte Binärdateien mit eingeschaltetem Free-Threading zu installieren (siehe PEP 703), solltest du „Customize installation“ wählen. Auf der zweiten Optionsseite findet sich das Kontrollkästchen „Download free-threaded binaries“.

Mit dieser Option werden zusätzliche Binärdateien an denselben Ort wie die Haupt-Python-Installation heruntergeladen und installiert. Die ausführbare Hauptdatei heißt python3.13t.exe, und andere Binärdateien erhalten entweder ein Suffix t oder ein vollständiges ABI-Suffix. Python-Quelldateien und beiliegende Abhängigkeiten von Dritten werden mit der Hauptinstallation gemeinsam genutzt.

Die Free-Threading-Version wird als gewöhnliche Python-Installation mit dem Tag 3.13t registriert (mit einem Suffix -32 oder -arm64, wie auf diesen Plattformen üblich). So können Werkzeuge sie finden, und der Python Install Manager unterstützt py.exe -3.13t. Beachte, dass der Starter py.exe -3 (oder einen Shebang python3) als „die neueste 3.x-Installation“ auffasst, wobei er die Free-Threading-Binärdateien den gewöhnlichen vorzieht, py.exe -3.13 dagegen nicht. Wenn du die kurze Form der Option verwendest, ziehst du es vielleicht vor, die Free-Threading-Binärdateien zunächst nicht zu installieren.

Um die Installationsoption auf der Befehlszeile anzugeben, verwende Include_freethreaded=1. Unter Ohne Herunterladen installieren steht, wie du die zusätzlichen Binärdateien vorab für eine Offline-Installation herunterlädst. Die Optionen zum Einbeziehen von Debugsymbolen und -binärdateien gelten auch für die Free-Threading-Builds.

Free-Threading-Binärdateien gibt es auch auf nuget.org.

4.12. Python-Starter für Windows (veraltet)

Veraltet ab Version 3.14: Der Starter und diese Dokumentation wurden durch den oben beschriebenen Python Install Manager ersetzt. Beides bleibt vorübergehend aus historischem Interesse erhalten.

Added in version 3.3.

Der Python-Starter für Windows ist ein Hilfsprogramm, das beim Auffinden und Ausführen verschiedener Python-Versionen hilft. Er erlaubt Skripten (oder der Befehlszeile), eine bestimmte Python-Version zu bevorzugen, und findet und führt diese Version aus.

Anders als die Variable PATH wählt der Starter die passendste Python-Version richtig aus. Er zieht Installationen je Benutzer den systemweiten vor und ordnet nach Sprachversion, statt die zuletzt installierte Version zu nehmen.

Der Starter wurde ursprünglich in PEP 397 festgelegt.

4.12.1. Los geht’s

4.12.1.1. Von der Befehlszeile

Geändert in Version 3.6.

Systemweite Installationen von Python 3.3 und neuer legen den Starter in deinen PATH. Der Starter ist mit allen verfügbaren Python-Versionen verträglich, es ist also unerheblich, welche Version installiert ist. Um zu prüfen, ob der Starter verfügbar ist, führe den folgenden Befehl an der Eingabeaufforderung aus:

py

Du solltest feststellen, dass die neueste installierte Python-Version startet — sie lässt sich wie üblich verlassen, und alle zusätzlich angegebenen Befehlszeilenargumente werden direkt an Python weitergegeben.

Wenn mehrere Python-Versionen installiert sind (etwa 3.7 und 3.15), ist dir aufgefallen, dass Python 3.15 gestartet wurde — um Python 3.7 zu starten, versuche den Befehl:

py -3.7

Wenn du die neueste installierte Version von Python 2 möchtest, versuche den Befehl:

py -2

Wenn du den folgenden Fehler siehst, ist der Starter nicht installiert:

'py' is not recognized as an internal or external command,
operable program or batch file.

Der Befehl:

py --list

zeigt die derzeit installierte Python-Version beziehungsweise die installierten Versionen an.

Das Argument -x.y ist die Kurzform des Arguments -V:Company/Tag, mit dem sich eine bestimmte Python-Runtime auswählen lässt, auch eine, die nicht von python.org stammt. Jede nach PEP 514 registrierte Runtime ist auffindbar. Der Befehl --list führt alle verfügbaren Runtimes im Format -V: auf.

Beim Argument -V: schränkt die Angabe der Company die Auswahl auf Runtimes dieses Anbieters ein, während die Angabe nur des Tags unter allen Anbietern auswählt. Beachte, dass ein fehlender Schrägstrich ein Tag bedeutet:

# Eine beliebige mit '3.*' gekennzeichnete Runtime auswählen
py -V:3

# Eine beliebige veröffentlichte Runtime von 'PythonCore' auswählen
py -V:PythonCore/

# Die neueste Python-3-Runtime von PythonCore auswählen
py -V:PythonCore/3

Die Kurzform des Arguments (-3) wählt immer nur aus den Kern-Veröffentlichungen von Python und nicht aus anderen Distributionen. Die längere Form (-V:3) wählt dagegen aus allen.

Die Company wird auf die ganze Zeichenkette abgeglichen, ohne Rücksicht auf Groß- und Kleinschreibung. Das Tag wird entweder auf die ganze Zeichenkette oder auf ein Präfix abgeglichen, sofern das nächste Zeichen ein Punkt oder ein Bindestrich ist. So passt -V:3.1 auf 3.1-32, aber nicht auf 3.10. Tags werden numerisch sortiert (3.10 ist neuer als 3.1), aber als Text verglichen (-V:3.01 passt nicht auf 3.1).

4.12.1.2. Virtuelle Umgebungen

Added in version 3.5.

Wird der Starter ohne ausdrückliche Angabe einer Python-Version aufgerufen und ist eine virtuelle Umgebung aktiv (angelegt mit dem Modul venv der Standardbibliothek oder dem externen Werkzeug virtualenv), führt der Starter den Interpreter der virtuellen Umgebung aus und nicht den globalen. Um den globalen Interpreter auszuführen, deaktiviere entweder die virtuelle Umgebung oder gib die globale Python-Version ausdrücklich an.

4.12.1.3. Aus einem Skript

Legen wir ein Python-Testskript an — erstelle eine Datei namens hello.py mit folgendem Inhalt

#! python
import sys
sys.stdout.write("hello from Python %s\n" % (sys.version,))

Führe aus dem Verzeichnis, in dem hello.py liegt, den folgenden Befehl aus:

py hello.py

Du solltest sehen, dass die Versionsnummer deiner neuesten Installation von Python 2.x ausgegeben wird. Versuche jetzt, die erste Zeile zu ändern in:

#! python3

Beim erneuten Ausführen des Befehls sollten nun die Angaben zum neuesten Python 3.x erscheinen. Wie bei den obigen Befehlszeilenbeispielen kannst du einen genaueren Versionszusatz angeben. Wenn Python 3.7 installiert ist, versuche, die erste Zeile in #! python3.7 zu ändern, dann sollten die Versionsangaben von 3.7 ausgegeben werden.

Beachte, dass ein bloßes „python“ — anders als bei interaktiver Verwendung — die neueste installierte Version von Python 2.x verwendet. Das dient der Abwärtsverträglichkeit und der Verträglichkeit mit Unix, wo der Befehl python üblicherweise Python 2 meint.

4.12.1.4. Über Dateiverknüpfungen

Der Starter sollte bei seiner Installation mit Python-Dateien verknüpft worden sein (also mit .py-, .pyw- und .pyc-Dateien). Das heißt, wenn du eine dieser Dateien im Windows-Explorer doppelt anklickst, wird der Starter verwendet, und du kannst daher dieselben oben beschriebenen Mittel nutzen, um im Skript die zu verwendende Version anzugeben.

Der wesentliche Vorteil dabei ist, dass ein einziger Starter je nach Inhalt der ersten Zeile gleichzeitig mehrere Python-Versionen unterstützen kann.

4.12.2. Shebang-Zeilen

Beginnt die erste Zeile einer Skriptdatei mit #!, spricht man von einer „Shebang“-Zeile. Linux und andere unixartige Betriebssysteme unterstützen solche Zeilen von Haus aus, und dort werden sie häufig verwendet, um anzugeben, wie ein Skript ausgeführt werden soll. Dieser Starter erlaubt dasselbe für Python-Skripte unter Windows, und die obigen Beispiele zeigen die Verwendung.

Damit Shebang-Zeilen in Python-Skripten zwischen Unix und Windows übertragbar bleiben, unterstützt dieser Starter mehrere „virtuelle“ Befehle, mit denen sich der zu verwendende Interpreter angeben lässt. Die unterstützten virtuellen Befehle sind:

• /usr/bin/env

• /usr/bin/python

• /usr/local/bin/python

• python

Beginnt die erste Zeile deines Skripts zum Beispiel mit

#! /usr/bin/python

Dann wird das Standard-Python oder eine aktive virtuelle Umgebung ermittelt und verwendet. Da viele für Unix geschriebene Python-Skripte diese Zeile schon enthalten, solltest du feststellen, dass sich solche Skripte ohne Änderung mit dem Starter verwenden lassen. Wenn du unter Windows ein neues Skript schreibst, das auch unter Unix nützlich sein soll, solltest du eine der Shebang-Zeilen verwenden, die mit /usr beginnen.

An jeden der obigen virtuellen Befehle lässt sich eine ausdrückliche Version anhängen (entweder nur die Hauptversion oder Haupt- und Nebenversion). Außerdem lässt sich die 32-Bit-Version anfordern, indem nach der Nebenversion „-32“ angefügt wird. Das heißt, /usr/bin/python3.7-32 fordert die Verwendung des 32-Bit-Python 3.7 an. Ist eine virtuelle Umgebung aktiv, wird die Version ignoriert und die Umgebung verwendet.

Added in version 3.7: Ab Python-Starter 3.7 lässt sich mit dem Suffix „-64“ die 64-Bit-Version anfordern. Außerdem lassen sich Hauptversion und Architektur ohne Nebenversion angeben (also /usr/bin/python3-64).

Geändert in Version 3.11: Das Suffix „-64“ ist veraltet und bedeutet jetzt „jede Architektur, die nicht nachweislich i386/32-Bit ist“. Um eine bestimmte Umgebung anzufordern, verwende das neue Argument -V:TAG mit dem vollständigen Tag.

Geändert in Version 3.13: Virtuelle Befehle, die auf python verweisen, ziehen nun eine aktive virtuelle Umgebung der Suche in PATH vor. Damit sind Fälle abgedeckt, in denen der Shebang /usr/bin/env python3 angibt, python3.exe in der aktiven Umgebung aber nicht vorhanden ist.

Die Shebang-Form /usr/bin/env hat noch eine besondere Eigenschaft. Bevor nach installierten Python-Interpretern gesucht wird, durchsucht diese Form den ausführbaren PATH nach einer ausführbaren Python-Datei, deren Name dem ersten Argument entspricht. Das entspricht dem Verhalten des Unix-Programms env, das eine Suche in PATH durchführt. Lässt sich keine ausführbare Datei finden, die zum ersten Argument nach dem Befehl env passt, beginnt das Argument aber mit python, wird es so behandelt wie bei den anderen virtuellen Befehlen. Die Umgebungsvariable PYLAUNCHER_NO_SEARCH_PATH lässt sich (auf einen beliebigen Wert) setzen, um diese Suche in PATH zu überspringen.

Shebang-Zeilen, die auf keines dieser Muster passen, werden im Abschnitt [commands] der .INI-Datei des Starters nachgeschlagen. Damit lassen sich bestimmte Befehle so behandeln, wie es für dein System sinnvoll ist. Der Name des Befehls muss ein einzelnes Argument sein (keine Leerzeichen in der ausführbaren Datei des Shebangs), und der eingesetzte Wert ist der vollständige Pfad zur ausführbaren Datei (in der .INI angegebene zusätzliche Argumente werden als Teil des Dateinamens in Anführungszeichen gesetzt).

[commands]
/bin/xpython=C:\Program Files\XPython\python.exe

Alle Befehle, die nicht in der .INI-Datei zu finden sind, werden als Windows-Pfade zu ausführbaren Dateien behandelt, die absolut oder relativ zum Verzeichnis der Skriptdatei sind. Das ist eine Bequemlichkeit für Skripte, die nur unter Windows laufen, etwa von einem Installationsprogramm erzeugte, denn dieses Verhalten ist mit unixartigen Shells nicht vereinbar. Diese Pfade dürfen in Anführungszeichen stehen und mehrere Argumente enthalten. Danach werden der Pfad zum Skript und etwaige weitere Argumente angehängt.

4.12.3. Argumente in Shebang-Zeilen

Die Shebang-Zeilen können auch zusätzliche Optionen angeben, die an den Python-Interpreter weitergegeben werden. Wenn du zum Beispiel diese Shebang-Zeile hast:

#! /usr/bin/python -v

dann wird Python mit der Option -v gestartet

4.12.4. Anpassung

4.12.4.1. Anpassung über INI-Dateien

Der Starter sucht nach zwei .ini-Dateien — py.ini im Anwendungsdatenverzeichnis des aktuellen Benutzers (%LOCALAPPDATA% oder $env:LocalAppData) und py.ini im Verzeichnis des Starters. Dieselben .ini-Dateien werden sowohl für die „Konsolen“-Fassung des Starters (also py.exe) als auch für die „Windows“-Fassung (also pyw.exe) verwendet.

Anpassungen im „Anwendungsverzeichnis“ haben Vorrang vor denen neben der ausführbaren Datei, sodass ein Benutzer, der möglicherweise keinen Schreibzugriff auf die .ini-Datei neben dem Starter hat, Befehle in dieser globalen .ini-Datei überschreiben kann.

4.12.4.2. Standard-Python-Versionen anpassen

In manchen Fällen lässt sich einem Befehl ein Versionszusatz mitgeben, der festlegt, welche Python-Version der Befehl verwendet. Ein Versionszusatz beginnt mit einer Hauptversionsnummer und kann wahlweise von einem Punkt („.“) und einer Nebenversionsangabe gefolgt werden. Außerdem lässt sich durch Anfügen von „-32“ oder „-64“ angeben, ob eine 32- oder 64-Bit-Umsetzung angefordert wird.

Die Shebang-Zeile #!python hat zum Beispiel keinen Versionszusatz, während #!python3 einen Versionszusatz hat, der nur eine Hauptversion angibt.

Finden sich in einem Befehl keine Versionszusätze, lässt sich die Umgebungsvariable PY_PYTHON setzen, um den Standard-Versionszusatz anzugeben. Ist sie nicht gesetzt, lautet die Vorgabe „3“. Die Variable darf jeden Wert annehmen, der auf der Befehlszeile übergeben werden kann, etwa „3“, „3.7“, „3.7-32“ oder „3.7-64“. (Beachte, dass die Option „-64“ nur beim Starter ab Python 3.7 verfügbar ist.)

Finden sich keine Nebenversionszusätze, lässt sich die Umgebungsvariable PY_PYTHON{major} setzen (wobei {major} der oben ermittelte aktuelle Hauptversionszusatz ist), um die vollständige Version anzugeben. Findet sich keine solche Option, zählt der Starter die installierten Python-Versionen auf und verwendet die neueste gefundene Nebenveröffentlichung zur Hauptversion. Das ist wahrscheinlich, aber nicht garantiert die zuletzt installierte Version dieser Familie.

Sind unter 64-Bit-Windows die 32- und die 64-Bit-Umsetzung derselben Python-Version (Haupt.Neben) installiert, wird immer die 64-Bit-Version vorgezogen. Das gilt für die 32- wie für die 64-Bit-Umsetzung des Starters — ein 32-Bit-Starter führt bevorzugt eine 64-Bit-Python-Installation der angegebenen Version aus, sofern vorhanden. So lässt sich das Verhalten des Starters vorhersagen, wenn man nur weiß, welche Versionen auf dem PC installiert sind, ohne die Reihenfolge der Installation zu kennen (also ohne zu wissen, ob zuletzt eine 32- oder eine 64-Bit-Version von Python und der zugehörige Starter installiert wurde). Wie oben erwähnt, lässt sich dieses Verhalten mit einem optionalen Suffix „-32“ oder „-64“ an der Versionsangabe ändern.

Beispiele:

• Sind keine einschlägigen Optionen gesetzt, verwenden die Befehle python und python2 die neueste installierte Version von Python 2.x, und der Befehl python3 verwendet das neueste installierte Python 3.x.

• Der Befehl python3.7 zieht überhaupt keine Optionen heran, da die Versionen vollständig angegeben sind.

• Bei PY_PYTHON=3 verwenden die Befehle python und python3 beide die neueste installierte Python-3-Version.

• Bei PY_PYTHON=3.7-32 verwendet der Befehl python die 32-Bit-Umsetzung von 3.7, während der Befehl python3 das neueste installierte Python verwendet (PY_PYTHON wurde überhaupt nicht herangezogen, da eine Hauptversion angegeben war).

• Bei PY_PYTHON=3 und PY_PYTHON3=3.7 verwenden die Befehle python und python3 beide ausdrücklich 3.7

Neben Umgebungsvariablen lassen sich dieselben Einstellungen in der .INI-Datei des Starters vornehmen. Der Abschnitt in der INI-Datei heißt [defaults], und der Name des Schlüssels entspricht dem der Umgebungsvariablen ohne das führende Präfix PY_ (beachte, dass die Schlüsselnamen in der INI-Datei ohne Rücksicht auf Groß- und Kleinschreibung gelesen werden). Der Inhalt einer Umgebungsvariablen überschreibt die Angaben in der INI-Datei.

Zum Beispiel:

• PY_PYTHON=3.7 zu setzen entspricht einer INI-Datei mit folgendem Inhalt:

[defaults]
python=3.7

• PY_PYTHON=3 und PY_PYTHON3=3.7 zu setzen entspricht einer INI-Datei mit folgendem Inhalt:

[defaults]
python=3
python3=3.7

4.12.5. Diagnose

Ist eine Umgebungsvariable PYLAUNCHER_DEBUG gesetzt (auf einen beliebigen Wert), gibt der Starter Diagnoseangaben auf stderr aus (also auf die Konsole). Diese Angaben sind gleichzeitig weitschweifig und knapp, sollten dir aber zeigen, welche Python-Versionen gefunden wurden, warum eine bestimmte Version gewählt wurde und mit welcher Befehlszeile das Ziel-Python genau ausgeführt wurde. Sie sind vor allem zum Testen und zur Fehlersuche gedacht.

4.12.6. Trockenlauf

Ist eine Umgebungsvariable PYLAUNCHER_DRYRUN gesetzt (auf einen beliebigen Wert), gibt der Starter den Befehl aus, den er ausgeführt hätte, startet Python aber nicht wirklich. Das kann für Werkzeuge nützlich sein, die mit dem Starter Python aufspüren und es dann selbst starten möchten. Beachte, dass der auf die Standardausgabe geschriebene Befehl immer mit UTF-8 kodiert ist und in der Konsole möglicherweise nicht richtig dargestellt wird.

4.12.7. Installation bei Bedarf

Ist eine Umgebungsvariable PYLAUNCHER_ALLOW_INSTALL gesetzt (auf einen beliebigen Wert) und ist die verlangte Python-Version nicht installiert, aber im Microsoft Store verfügbar, versucht der Starter, sie zu installieren. Dafür kann ein Eingreifen des Benutzers nötig sein, und du musst den Befehl möglicherweise erneut ausführen.

Eine weitere Variable PYLAUNCHER_ALWAYS_INSTALL bewirkt, dass der Starter immer versucht, Python zu installieren, selbst wenn es gefunden wird. Das ist vor allem zum Testen gedacht (und sollte mit PYLAUNCHER_DRYRUN verwendet werden).

4.12.8. Rückgabewerte

Der Python-Starter kann die folgenden Beendigungswerte zurückgeben. Leider lassen sie sich nicht vom Beendigungswert von Python selbst unterscheiden.

Die Namen der Werte sind die im Quellcode verwendeten und dienen nur dem Nachschlagen. Es gibt keine Möglichkeit, sie abzurufen oder aufzulösen, außer diese Seite zu lesen. Die Einträge stehen in alphabetischer Reihenfolge der Namen.

Name	Wert	Beschreibung
RC_BAD_VENV_CFG	107	Eine pyvenv.cfg wurde gefunden, ist aber beschädigt.
RC_CREATE_PROCESS	101	Python konnte nicht gestartet werden.
RC_INSTALLING	111	Eine Installation wurde angestoßen, der Befehl muss aber nach deren Abschluss erneut ausgeführt werden.
RC_INTERNAL_ERROR	109	Unerwarteter Fehler. Bitte melde einen Fehlerbericht.
RC_NO_COMMANDLINE	108	Die Befehlszeile konnte nicht vom Betriebssystem bezogen werden.
RC_NO_PYTHON	103	Die verlangte Version konnte nicht gefunden werden.
RC_NO_VENV_CFG	106	Eine pyvenv.cfg war erforderlich, wurde aber nicht gefunden.