runpy — Module zum Auffinden und Ausführen von Python-Modulen¶
Quellcode: Lib/runpy.py
Das Modul runpy wird verwendet, um Python-Module aufzufinden und auszuführen, ohne sie vorher zu importieren. Sein Hauptzweck ist die Implementierung des -m Kommandozeilenschalters, der es ermöglicht, Skripte über den Python-Modul-Namensraum und nicht über das Dateisystem zu lokalisieren.
Beachten Sie, dass dies *kein* Sandbox-Modul ist - aller Code wird im aktuellen Prozess ausgeführt, und alle Nebeneffekte (wie z. B. zwischengespeicherte Importe anderer Module) bleiben bestehen, nachdem die Funktionen zurückgekehrt sind.
Darüber hinaus wird nicht garantiert, dass Funktionen und Klassen, die vom ausgeführten Code definiert wurden, nach der Rückkehr einer Funktion von runpy korrekt funktionieren. Wenn diese Einschränkung für einen bestimmten Anwendungsfall nicht akzeptabel ist, ist importlib wahrscheinlich eine geeignetere Wahl als dieses Modul.
Das Modul runpy bietet zwei Funktionen
- runpy.run_module(mod_name, init_globals=None, run_name=None, alter_sys=False)¶
Führt den Code des angegebenen Moduls aus und gibt das resultierende Globals-Wörterbuch des Moduls zurück. Der Code des Moduls wird zuerst mithilfe des Standard-Importmechanismus gefunden (siehe PEP 302 für Details) und dann in einem frischen Modul-Namensraum ausgeführt.
Das Argument mod_name sollte ein absoluter Modulname sein. Wenn der Modulname auf ein Paket und nicht auf ein normales Modul verweist, dann wird dieses Paket importiert und anschließend das Untermodul
__main__innerhalb dieses Pakets ausgeführt und das resultierende Modul-Globals-Wörterbuch zurückgegeben.Das optionale Wörterbuchargument init_globals kann verwendet werden, um das Globals-Wörterbuch des Moduls vor der Ausführung des Codes vorab zu füllen. init_globals wird nicht geändert. Wenn eine der unten aufgeführten speziellen globalen Variablen in init_globals definiert ist, werden diese Definitionen von
run_module()überschrieben.Die speziellen globalen Variablen
__name__,__spec__,__file__,__cached__,__loader__und__package__werden im Globals-Wörterbuch gesetzt, bevor der Modulcode ausgeführt wird. (Beachten Sie, dass dies ein minimaler Satz von Variablen ist - andere Variablen können implizit als Implementierungsdetail des Interpreters gesetzt werden.)__name__wird auf run_name gesetzt, wenn dieses optionale Argument nichtNoneist, aufmod_name + '.__main__', wenn das benannte Modul ein Paket ist, und andernfalls auf das Argument mod_name.__spec__wird für das *tatsächlich* importierte Modul entsprechend gesetzt (d. h.__spec__.nameist immer mod_name odermod_name + '.__main__', niemals run_name).__file__,__cached__,__loader__und__package__werden basierend auf der Modulspezifikation *normal* gesetzt (siehe normal gesetzt).Wenn das Argument alter_sys bereitgestellt wird und zu
Trueausgewertet wird, dann wirdsys.argv[0]mit dem Wert von__file__aktualisiert undsys.modules[__name__]mit einem temporären Modulobjekt für das auszuführende Modul aktualisiert. Sowohlsys.argv[0]als auchsys.modules[__name__]werden vor der Rückkehr der Funktion auf ihre ursprünglichen Werte zurückgesetzt.Beachten Sie, dass diese Manipulation von
sysnicht Thread-sicher ist. Andere Threads können das teilweise initialisierte Modul sowie die geänderte Liste der Argumente sehen. Es wird empfohlen, dassys-Modul bei der Aufrufung dieser Funktion aus Thread-Code in Ruhe zu lassen.Siehe auch
Die Option
-mbietet eine gleichwertige Funktionalität von der Kommandozeile.Geändert in Version 3.1: Es wurde die Möglichkeit hinzugefügt, Pakete auszuführen, indem nach einem Untermodul
__main__gesucht wird.Geändert in Version 3.2: Die globale Variable
__cached__wurde hinzugefügt (siehe PEP 3147).Geändert in Version 3.4: Aktualisiert, um die von PEP 451 hinzugefügte Modulspezifikationsfunktion zu nutzen. Dies ermöglicht
__cached__korrekt für auf diese Weise ausgeführte Module zu setzen und stellt sicher, dass der tatsächliche Modulname immer als__spec__.namezugänglich ist.Geändert in Version 3.12: Das Setzen von
__cached__,__loader__und__package__ist veraltet. SieheModuleSpecfür Alternativen.
- runpy.run_path(path_name, init_globals=None, run_name=None)¶
Führt den Code an dem benannten Dateisystemort aus und gibt das resultierende Globals-Wörterbuch des Moduls zurück. Wie bei einem Skriptnamen, der der CPython-Kommandozeile übergeben wird, kann file_path sich auf eine Python-Quelldatei, eine kompilierte Bytecode-Datei oder einen gültigen Eintrag in
sys.pathbeziehen, der ein__main__-Modul enthält (z. B. eine Zip-Datei mit einer__main__.py-Datei auf oberster Ebene).Für ein einfaches Skript wird der angegebene Code einfach in einem neuen Modul-Namensraum ausgeführt. Für einen gültigen Eintrag in
sys.path(typischerweise eine Zip-Datei oder ein Verzeichnis) wird der Eintrag zuerst am Anfang vonsys.pathhinzugefügt. Die Funktion sucht dann nach einem__main__-Modul und führt es mit dem aktualisierten Pfad aus. Beachten Sie, dass es keinen besonderen Schutz gibt, um eine bereits vorhandene__main__-Eintragung an einer anderen Stelle insys.pathzu umgehen, wenn kein solches Modul am angegebenen Ort vorhanden ist.Das optionale Wörterbuchargument init_globals kann verwendet werden, um das Globals-Wörterbuch des Moduls vor der Ausführung des Codes vorab zu füllen. init_globals wird nicht geändert. Wenn eine der unten aufgeführten speziellen globalen Variablen in init_globals definiert ist, werden diese Definitionen von
run_path()überschrieben.Die speziellen globalen Variablen
__name__,__spec__,__file__,__cached__,__loader__und__package__werden im Globals-Wörterbuch gesetzt, bevor der Modulcode ausgeführt wird. (Beachten Sie, dass dies ein minimaler Satz von Variablen ist - andere Variablen können implizit als Implementierungsdetail des Interpreters gesetzt werden.)__name__wird auf run_name gesetzt, wenn dieses optionale Argument nichtNoneist, und andernfalls auf'<run_path>'.Wenn file_path direkt auf eine Skriptdatei verweist (sei es als Quelle oder als vorkompilierter Bytecode), dann wird
__file__auf file_path gesetzt, und__spec__,__cached__,__loader__und__package__werden alle aufNonegesetzt.Wenn file_path ein Verweis auf einen gültigen Eintrag in
sys.pathist, dann wird__spec__entsprechend für das importierte__main__-Modul gesetzt (d. h.__spec__.nameist immer__main__).__file__,__cached__,__loader__und__package__werden basierend auf der Modulspezifikation *normal* gesetzt (siehe normal gesetzt).Mehrere Änderungen werden auch am Modul
sysvorgenommen. Erstens kannsys.pathwie oben beschrieben geändert werden.sys.argv[0]wird mit dem Wert von file_path aktualisiert undsys.modules[__name__]mit einem temporären Modulobjekt für das auszuführende Modul aktualisiert. Alle Änderungen an Elementen insyswerden zurückgesetzt, bevor die Funktion zurückkehrt.Beachten Sie, dass im Gegensatz zu
run_module()die Änderungen ansysin dieser Funktion nicht optional sind, da diese Anpassungen für die Ausführung vonsys.path-Einträgen unerlässlich sind. Da die Einschränkungen der Thread-Sicherheit weiterhin gelten, sollte die Verwendung dieser Funktion in Thread-Code entweder mit dem Import-Lock serialisiert oder an einen separaten Prozess delegiert werden.Siehe auch
Interface-Optionen für gleichwertige Funktionalität auf der Kommandozeile (
python path/to/script).Hinzugefügt in Version 3.2.
Geändert in Version 3.4: Aktualisiert, um die von PEP 451 hinzugefügte Modulspezifikationsfunktion zu nutzen. Dies ermöglicht
__cached__korrekt zu setzen, wenn__main__aus einem gültigensys.path-Eintrag importiert wird, anstatt direkt ausgeführt zu werden.Geändert in Version 3.12: Das Setzen von
__cached__,__loader__und__package__ist veraltet.
Siehe auch
- PEP 338 – Ausführen von Modulen als Skripte
PEP geschrieben und implementiert von Nick Coghlan.
- PEP 366 – Explizite relative Importe im Hauptmodul
PEP geschrieben und implementiert von Nick Coghlan.
- PEP 451 – Ein ModuleSpec-Typ für das Importsystem
PEP geschrieben und implementiert von Eric Snow
Kommandozeile und Umgebung - Details zur CPython-Kommandozeile
Die Funktion importlib.import_module()