`sys` — Systemspezifische Parameter und Funktionen¶

Dieses Modul stellt Zugriff auf einige vom Interpreter verwendete oder verwaltete Variablen sowie auf Funktionen, die stark mit dem Interpreter interagieren, bereit. Es ist immer verfügbar. Sofern nicht ausdrücklich anders angegeben, sind alle Variablen schreibgeschützt.

sys.abiflags¶: Auf POSIX-Systemen, auf denen Python mit dem Standard-configure-Skript erstellt wurde, enthält dies die ABI-Flags gemäß PEP 3149.

Hinzugefügt in Version 3.2.

Geändert in Version 3.8: Standard-Flags wurden zu einer leeren Zeichenkette (m-Flag für pymalloc wurde entfernt).

Verfügbarkeit: Unix.

sys.addaudithook(hook)¶

Hängt den aufrufbaren hook an die Liste der aktiven Audit-Hooks für den aktuellen (Sub-)Interpreter an.

Wenn ein Audit-Ereignis über die Funktion sys.audit() ausgelöst wird, wird jeder Hook in der Reihenfolge seiner Hinzufügung mit dem Ereignisnamen und dem Tupel von Argumenten aufgerufen. Native Hooks, die von PySys_AddAuditHook() hinzugefügt wurden, werden zuerst aufgerufen, gefolgt von Hooks, die im aktuellen (Sub-)Interpreter hinzugefügt wurden. Hooks können dann das Ereignis protokollieren, eine Ausnahme auslösen, um die Operation abzubrechen, oder den Prozess vollständig beenden.

Beachten Sie, dass Audit-Hooks in erster Linie dazu dienen, Informationen über interne oder anderweitig nicht beobachtbare Aktionen zu sammeln, sei es von Python selbst oder von in Python geschriebenen Bibliotheken. Sie sind nicht für die Implementierung einer „Sandbox“ geeignet. Insbesondere kann bösartiger Code Hooks, die mit dieser Funktion hinzugefügt wurden, trivial deaktivieren oder umgehen. Mindestens müssen sicherheitsrelevante Hooks über die C-API PySys_AddAuditHook() vor der Initialisierung der Laufzeitumgebung hinzugefügt werden, und alle Module, die eine beliebige Speicheränderung ermöglichen (wie z. B. ctypes), sollten vollständig entfernt oder eng überwacht werden.

Der Aufruf von sys.addaudithook() löst selbst ein Audit-Ereignis namens sys.addaudithook ohne Argumente aus. Wenn ein vorhandener Hook eine Ausnahme auslöst, die von RuntimeError abgeleitet ist, wird der neue Hook nicht hinzugefügt und die Ausnahme unterdrückt. Folglich können Aufrufer nicht davon ausgehen, dass ihr Hook hinzugefügt wurde, es sei denn, sie kontrollieren alle vorhandenen Hooks.

Siehe die Tabelle der Audit-Ereignisse für alle von CPython ausgelösten Ereignisse und PEP 578 für die ursprüngliche Design-Diskussion.

Hinzugefügt in Version 3.8.

Geändert in Version 3.8.1: Ausnahmen, die von Exception, aber nicht von RuntimeError abgeleitet sind, werden nicht mehr unterdrückt.

CPython-Implementierungsdetail: Wenn das Tracing aktiviert ist (siehe settrace()), werden Python-Hooks nur getraced, wenn der aufrufbare Wert ein Mitglied __cantrace__ hat, das auf einen wahren Wert gesetzt ist. Andernfalls überspringen Trace-Funktionen den Hook.

sys.argv¶

Die Liste der Kommandozeilenargumente, die an ein Python-Skript übergeben werden. argv[0] ist der Skriptname (es ist betriebssystemabhängig, ob dies ein vollständiger Pfad ist oder nicht). Wenn der Befehl mit der Kommandozeilenoption -c des Interpreters ausgeführt wurde, wird argv[0] auf die Zeichenkette '-c' gesetzt. Wenn kein Skriptname an den Python-Interpreter übergeben wurde, ist argv[0] die leere Zeichenkette.

Um über die Standardeingabe oder die Liste der auf der Kommandozeile angegebenen Dateien zu iterieren, siehe das Modul fileinput.

Siehe auch sys.orig_argv.

Hinweis

Unter Unix werden Kommandozeilenargumente als Bytes vom Betriebssystem übergeben. Python dekodiert sie mit der Dateisystemkodierung und dem Fehlerhandler „surrogateescape“. Wenn Sie die ursprünglichen Bytes benötigen, können Sie sie über [os.fsencode(arg) for arg in sys.argv] erhalten.

sys.audit(event, *args)¶

Löst ein Audit-Ereignis aus und löst alle aktiven Audit-Hooks aus. event ist eine Zeichenkette, die das Ereignis identifiziert, und args kann optionale Argumente mit weiteren Informationen über das Ereignis enthalten. Die Anzahl und die Typen der Argumente für ein bestimmtes Ereignis gelten als öffentliche und stabile API und sollten zwischen den Versionen nicht geändert werden.

Ein Audit-Ereignis ist zum Beispiel os.chdir benannt. Dieses Ereignis hat ein Argument namens path, das das angeforderte neue Arbeitsverzeichnis enthält.

sys.audit() ruft die vorhandenen Audit-Hooks auf, übergibt den Ereignisnamen und die Argumente und löst die erste Ausnahme von einem Hook erneut aus. Im Allgemeinen sollte eine ausgelöste Ausnahme nicht behandelt und der Prozess so schnell wie möglich beendet werden. Dies ermöglicht es Hook-Implementierungen zu entscheiden, wie auf bestimmte Ereignisse reagiert werden soll: Sie können das Ereignis einfach protokollieren oder die Operation durch Auslösen einer Ausnahme abbrechen.

Hooks werden über die Funktionen sys.addaudithook() oder PySys_AddAuditHook() hinzugefügt.

Das native Äquivalent dieser Funktion ist PySys_Audit(). Wenn möglich, ist die Verwendung der nativen Funktion vorzuziehen.

Siehe die Tabelle der Audit-Ereignisse für alle von CPython ausgelösten Ereignisse.

Hinzugefügt in Version 3.8.

sys.base_exec_prefix¶

Äquivalent zu exec_prefix, aber bezieht sich auf die Basis-Python-Installation.

Bei Ausführung unter Virtuellen Umgebungen wird exec_prefix auf den Präfix der virtuellen Umgebung überschrieben. base_exec_prefix hingegen ändert sich nicht und zeigt immer auf die Basis-Python-Installation. Weitere Informationen finden Sie unter Virtuelle Umgebungen.

Hinzugefügt in Version 3.3.

sys.base_prefix¶

Äquivalent zu prefix, aber bezieht sich auf die Basis-Python-Installation.

Bei Ausführung unter einer virtuellen Umgebung wird prefix auf den Präfix der virtuellen Umgebung überschrieben. base_prefix hingegen ändert sich nicht und zeigt immer auf die Basis-Python-Installation. Weitere Informationen finden Sie unter Virtuelle Umgebungen.

Hinzugefügt in Version 3.3.

sys.byteorder¶: Ein Indikator für die native Byte-Reihenfolge. Dieser hat den Wert 'big' auf Big-Endian-Plattformen (höchstwertiges Byte zuerst) und 'little' auf Little-Endian-Plattformen (niedrigstwertiges Byte zuerst).

sys.builtin_module_names¶

Ein Tupel von Zeichenketten, das die Namen aller Module enthält, die in diesen Python-Interpreter kompiliert sind. (Diese Information ist auf keine andere Weise verfügbar – modules.keys() listet nur die importierten Module auf.)

Siehe auch die Liste sys.stdlib_module_names.

sys.call_tracing(func, args)¶

Ruft func(*args) auf, während das Tracing aktiviert ist. Der Tracing-Zustand wird gespeichert und danach wiederhergestellt. Dies ist dazu gedacht, von einem Debugger von einem Kontrollpunkt aus aufgerufen zu werden, um anderen Code rekursiv zu debuggen oder zu profilieren.

Das Tracing wird während des Aufrufs einer von settrace() oder setprofile() festgelegten Tracing-Funktion ausgesetzt, um eine Endlosschleife zu vermeiden. call_tracing() ermöglicht die explizite Rekursion der Tracing-Funktion.

sys.copyright¶: Eine Zeichenkette, die das Urheberrecht bezüglich des Python-Interpreters enthält.

sys._clear_type_cache()¶

Löscht den internen Typ-Cache. Der Typ-Cache wird verwendet, um das Nachschlagen von Attributen und Methoden zu beschleunigen. Verwenden Sie die Funktion *nur*, um unnötige Referenzen während der Fehlersuche nach Referenzlecks zu entfernen.

Diese Funktion sollte nur für interne und spezialisierte Zwecke verwendet werden.

Veraltet seit Version 3.13: Verwenden Sie stattdessen die allgemeinere Funktion _clear_internal_caches().

sys._clear_internal_caches()¶: Löscht alle internen leistungsorientierten Caches. Verwenden Sie diese Funktion *nur*, um unnötige Referenzen und Speicherblöcke beim Suchen nach Lecks freizugeben.

Hinzugefügt in Version 3.13.

sys._current_frames()¶

Gibt ein Wörterbuch zurück, das die Kennung jedes Threads auf den obersten Stapelrahmen abbildet, der zu dem Zeitpunkt, zu dem die Funktion aufgerufen wird, in diesem Thread aktiv ist. Beachten Sie, dass Funktionen im Modul traceback den Aufrufstapel aus einem solchen Rahmen erstellen können.

Dies ist am nützlichsten für die Fehlersuche bei Deadlocks: Diese Funktion erfordert keine Kooperation der blockierten Threads, und die Aufrufstapel solcher Threads sind eingefroren, solange sie blockiert bleiben. Der für einen nicht blockierten Thread zurückgegebene Rahmen kann keine Beziehung zur aktuellen Aktivität dieses Threads haben, wenn der aufrufende Code den Rahmen untersucht.

Diese Funktion sollte nur für interne und spezialisierte Zwecke verwendet werden.

Löst ein Audit-Ereignis sys._current_frames ohne Argumente aus.

sys._current_exceptions()¶

Gibt ein Wörterbuch zurück, das die Kennung jedes Threads auf die oberste Ausnahme abbildet, die zu dem Zeitpunkt, zu dem die Funktion aufgerufen wird, in diesem Thread aktiv ist. Wenn ein Thread gerade keine Ausnahme behandelt, ist er nicht im Ergebniswörterbuch enthalten.

Dies ist am nützlichsten für statistisches Profiling.

Diese Funktion sollte nur für interne und spezialisierte Zwecke verwendet werden.

Löst ein Audit-Ereignis sys._current_exceptions ohne Argumente aus.

Geändert in Version 3.12: Jeder Wert im Wörterbuch ist nun eine einzelne Ausnahmeinstanz, anstatt eines 3-Tupels, wie es von sys.exc_info() zurückgegeben wird.

sys.breakpointhook()¶

Diese Hook-Funktion wird von der integrierten Funktion breakpoint() aufgerufen. Standardmäßig startet sie den pdb-Debugger, kann aber auf jede andere Funktion gesetzt werden, sodass Sie wählen können, welcher Debugger verwendet wird.

Die Signatur dieser Funktion hängt davon ab, was sie aufruft. Zum Beispiel erwartet die Standardbindung (z. B. pdb.set_trace()) keine Argumente, aber Sie können sie an eine Funktion binden, die zusätzliche Argumente (positionell und/oder Schlüsselwort) erwartet. Die integrierte Funktion breakpoint() übergibt ihre *args und **kws direkt weiter. Was auch immer breakpointhooks() zurückgibt, wird von breakpoint() zurückgegeben.

Die Standardimplementierung prüft zuerst die Umgebungsvariable PYTHONBREAKPOINT. Wenn diese auf "0" gesetzt ist, gibt die Funktion sofort zurück; d. h. sie ist eine No-Op. Wenn die Umgebungsvariable nicht gesetzt ist oder auf die leere Zeichenkette gesetzt ist, wird pdb.set_trace() aufgerufen. Andernfalls sollte diese Variable eine Funktion benennen, die ausgeführt werden soll, unter Verwendung der Punkt-Import-Nomenklatur von Python, z. B. package.subpackage.module.function. In diesem Fall würde package.subpackage.module importiert und das resultierende Modul müsste eine aufrufbare Funktion namens function() enthalten. Diese wird mit *args und **kws aufgerufen, und was auch immer function() zurückgibt, gibt sys.breakpointhook() an die integrierte Funktion breakpoint() zurück.

Beachten Sie, dass, wenn beim Importieren der von PYTHONBREAKPOINT benannten aufrufbaren Funktion etwas schief geht, eine RuntimeWarning gemeldet und der Breakpoint ignoriert wird.

Beachten Sie auch, dass, wenn sys.breakpointhook() programmatisch überschrieben wird, PYTHONBREAKPOINT *nicht* konsultiert wird.

Hinzugefügt in Version 3.7.

sys._debugmallocstats()¶

Gibt Low-Level-Informationen über den Zustand des CPython-Speicherallokators nach stderr aus.

Wenn Python im Debug-Modus erstellt wird (configure --with-pydebug Option), führt es auch einige aufwendige interne Konsistenzprüfungen durch.

Hinzugefügt in Version 3.3.

CPython-Implementierungsdetail: Diese Funktion ist spezifisch für CPython. Das genaue Ausgabeformat ist hier nicht definiert und kann sich ändern.

sys.dllhandle¶: Ganzzahl, die das Handle der Python-DLL angibt.

Verfügbarkeit: Windows.

sys.displayhook(value)¶

Wenn value nicht None ist, druckt diese Funktion repr(value) nach sys.stdout und speichert value in builtins._. Wenn repr(value) nicht mit dem Fehlerbehandler sys.stdout.errors (wahrscheinlich 'strict') nach sys.stdout.encoding kodiert werden kann, wird es mit dem Fehlerbehandler 'backslashreplace' nach sys.stdout.encoding kodiert.

sys.displayhook wird für das Ergebnis der Auswertung eines Ausdrucks aufgerufen, der in einer interaktiven Python-Sitzung eingegeben wurde. Die Anzeige dieser Werte kann angepasst werden, indem eine andere Funktion mit einem Argument an sys.displayhook zugewiesen wird.

Pseudocode

def displayhook(value):
    if value is None:
        return
    # Set '_' to None to avoid recursion
    builtins._ = None
    text = repr(value)
    try:
        sys.stdout.write(text)
    except UnicodeEncodeError:
        bytes = text.encode(sys.stdout.encoding, 'backslashreplace')
        if hasattr(sys.stdout, 'buffer'):
            sys.stdout.buffer.write(bytes)
        else:
            text = bytes.decode(sys.stdout.encoding, 'strict')
            sys.stdout.write(text)
    sys.stdout.write("\n")
    builtins._ = value

Geändert in Version 3.2: Verwendet den Fehlerbehandler 'backslashreplace' bei UnicodeEncodeError.

sys.dont_write_bytecode¶: Wenn dieser Wert wahr ist, versucht Python nicht, .pyc-Dateien beim Importieren von Quellmodulen zu schreiben. Dieser Wert wird initial basierend auf der Kommandozeilenoption -B und der Umgebungsvariable PYTHONDONTWRITEBYTECODE auf True oder False gesetzt, kann aber selbst gesetzt werden, um die Generierung von Bytecode-Dateien zu steuern.

sys._emscripten_info¶

Ein benanntes Tupel mit Informationen über die Umgebung auf der Plattform wasm32-emscripten. Das benannte Tupel ist provisorisch und kann sich in Zukunft ändern.

_emscripten_info.emscripten_version¶: Emscripten-Version als Tupel von Ganzzahlen (Major, Minor, Micro), z. B. (3, 1, 8).

_emscripten_info.runtime¶: Laufzeitzeichenkette, z. B. Browser-User-Agent, 'Node.js v14.18.2' oder 'UNKNOWN'.

_emscripten_info.pthreads¶: True, wenn Python mit Emscripten-Pthreads-Unterstützung kompiliert wurde.

_emscripten_info.shared_memory¶: True, wenn Python mit Shared-Memory-Unterstützung kompiliert wurde.

Verfügbarkeit: Emscripten.

Hinzugefügt in Version 3.11.

sys.pycache_prefix¶

Wenn dieser Wert gesetzt ist (nicht None), schreibt Python Bytecode-Cache .pyc-Dateien in einen parallelen Verzeichnisbaum, der an diesem Verzeichnis beginnt (und liest sie von dort), anstatt aus __pycache__-Verzeichnissen im Quellcodebaum. Alle __pycache__-Verzeichnisse im Quellcodebaum werden ignoriert und neue .pyc-Dateien werden im pycache-Präfix geschrieben. Wenn Sie also compileall als Pre-Build-Schritt verwenden, müssen Sie sicherstellen, dass Sie es mit demselben pycache-Präfix (falls vorhanden) ausführen, das Sie zur Laufzeit verwenden werden.

Ein relativer Pfad wird relativ zum aktuellen Arbeitsverzeichnis interpretiert.

Dieser Wert wird initial basierend auf dem Wert der Kommandozeilenoption -X pycache_prefix=PATH oder der Umgebungsvariable PYTHONPYCACHEPREFIX gesetzt (die Kommandozeile hat Vorrang). Wenn keines von beiden gesetzt ist, ist es None.

Hinzugefügt in Version 3.8.

sys.excepthook(type, value, traceback)¶

Diese Funktion gibt einen gegebenen Traceback und eine Ausnahme nach sys.stderr aus.

Wenn eine Ausnahme außer SystemExit ausgelöst und nicht abgefangen wird, ruft der Interpreter sys.excepthook mit drei Argumenten auf: der Ausnahmeklasse, der Ausnahmeinstanz und einem Traceback-Objekt. In einer interaktiven Sitzung geschieht dies kurz bevor die Kontrolle zur Eingabeaufforderung zurückkehrt; in einem Python-Programm geschieht dies kurz bevor das Programm beendet wird. Die Behandlung solcher Top-Level-Ausnahmen kann angepasst werden, indem eine andere Funktion mit drei Argumenten an sys.excepthook zugewiesen wird.

Löst ein Audit-Ereignis sys.excepthook mit den Argumenten hook, type, value, traceback aus, wenn eine nicht abgefangene Ausnahme auftritt. Wenn kein Hook gesetzt wurde, kann hook None sein. Wenn ein Hook eine Ausnahme auslöst, die von RuntimeError abgeleitet ist, wird der Aufruf des Hooks unterdrückt. Andernfalls wird die Audit-Hook-Ausnahme als nicht aufhebbar gemeldet und sys.excepthook aufgerufen.

Siehe auch

Die Funktion sys.unraisablehook() behandelt nicht aufhebbare Ausnahmen, und die Funktion threading.excepthook() behandelt Ausnahmen, die von threading.Thread.run() ausgelöst werden.

sys.__breakpointhook__¶
sys.__displayhook__¶
sys.__excepthook__¶
sys.__unraisablehook__¶: Diese Objekte enthalten die ursprünglichen Werte von breakpointhook, displayhook, excepthook und unraisablehook zu Beginn des Programms. Sie werden gespeichert, damit breakpointhook, displayhook und excepthook, unraisablehook wiederhergestellt werden können, falls sie durch fehlerhafte oder alternative Objekte ersetzt werden.

Hinzugefügt in Version 3.7: __breakpointhook__

Hinzugefügt in Version 3.8: __unraisablehook__

sys.exception()¶

Diese Funktion gibt, wenn sie während der Ausführung eines Ausnahmebehandlers aufgerufen wird (wie z. B. eine except- oder except*-Klausel), die von diesem Handler abgefangene Ausnahmeinstanz zurück. Wenn Ausnahmebehandler verschachtelt sind, ist nur die vom innersten Handler behandelte Ausnahme zugänglich.

Wenn kein Ausnahmebehandler ausgeführt wird, gibt diese Funktion None zurück.

Hinzugefügt in Version 3.11.

sys.exc_info()¶

Diese Funktion gibt die alte Darstellung der behandelten Ausnahme zurück. Wenn eine Ausnahme e gerade behandelt wird (sodass exception() e zurückgeben würde), gibt exc_info() das Tupel (type(e), e, e.__traceback__) zurück. Das heißt, ein Tupel, das den Typ der Ausnahme (eine Unterklasse von BaseException), die Ausnahme selbst und ein Traceback-Objekt enthält, das typischerweise den Aufrufstapel an der Stelle verkapselt, an der die Ausnahme zuletzt aufgetreten ist.

Wenn auf dem Stapel keine Ausnahme behandelt wird, gibt diese Funktion ein Tupel mit drei None-Werten zurück.

Geändert in Version 3.11: Die Felder type und traceback werden jetzt von value (der Ausnahmeinstanz) abgeleitet. Wenn also eine Ausnahme während der Behandlung geändert wird, spiegeln sich die Änderungen in den Ergebnissen nachfolgender Aufrufe von exc_info() wider.

sys.exec_prefix¶: Ein String, der das standortspezifische Verzeichispräfix angibt, an dem die plattformabhängigen Python-Dateien installiert sind; standardmäßig ist dies auch '/usr/local'. Dies kann zur Build-Zeit mit dem Argument --exec-prefix für das configure-Skript gesetzt werden. Insbesondere werden alle Konfigurationsdateien (z. B. die pyconfig.h Header-Datei) im Verzeichnis exec_prefix/lib/pythonX.Y/config installiert und gemeinsam genutzte Bibliotheksmodule werden in exec_prefix/lib/pythonX.Y/lib-dynload installiert, wobei X.Y die Versionsnummer von Python ist, z. B. 3.2.

Hinweis

Wenn eine virtuelle Umgebung aktiv ist, zeigt dieses exec_prefix auf die virtuelle Umgebung. Der Wert für die Python-Installation ist weiterhin über base_exec_prefix verfügbar. Weitere Informationen finden Sie unter Virtuelle Umgebungen.

Geändert in Version 3.14: Bei Ausführung in einer virtuellen Umgebung zeigen prefix und exec_prefix nun auf das Präfix der virtuellen Umgebung, anstatt auf site. Dies geschieht durch die Pfadinitialisierung. Das bedeutet, dass prefix und exec_prefix immer auf die virtuelle Umgebung zeigen, auch wenn site deaktiviert ist (-S).

sys.executable¶: Ein String, der den absoluten Pfad zur ausführbaren Binärdatei für den Python-Interpreter angibt, auf Systemen, bei denen dies sinnvoll ist. Wenn Python den tatsächlichen Pfad zu seiner ausführbaren Datei nicht ermitteln kann, ist sys.executable ein leerer String oder None.

sys.exit([arg])¶

Löst eine SystemExit-Exception aus, die die Absicht signalisiert, den Interpreter zu beenden.

Das optionale Argument arg kann eine Ganzzahl sein, die den Exit-Status angibt (standardmäßig null), oder ein Objekt eines anderen Typs. Wenn es eine Ganzzahl ist, wird null als "erfolgreiche Beendigung" betrachtet und jeder von null verschiedene Wert als "abnormale Beendigung" von Shells und dergleichen. Die meisten Systeme erfordern, dass dieser Wert im Bereich 0-127 liegt, und liefern andernfalls undefinierte Ergebnisse. Einige Systeme haben eine Konvention zur Zuweisung spezifischer Bedeutungen zu spezifischen Exit-Codes, aber diese sind generell unterentwickelt; Unix-Programme verwenden im Allgemeinen 2 für Fehler bei der Kommandozeilensyntax und 1 für alle anderen Arten von Fehlern. Wenn ein Objekt eines anderen Typs übergeben wird, ist None äquivalent zur Übergabe von null, und jedes andere Objekt wird auf stderr ausgegeben und führt zu einem Exit-Code von 1. Insbesondere ist sys.exit("eine Fehlermeldung") eine schnelle Möglichkeit, ein Programm im Fehlerfall zu beenden.

Da exit() letztendlich "nur" eine Ausnahme auslöst, wird der Prozess nur dann beendet, wenn sie im Haupt-Thread aufgerufen wird und die Ausnahme nicht abgefangen wird. Bereinigungsaktionen, die durch finally-Klauseln von try-Anweisungen angegeben sind, werden beachtet, und es ist möglich, den Beendigungsversuch auf einer höheren Ebene abzufangen.

Geändert in Version 3.6: Wenn ein Fehler bei der Bereinigung auftritt, nachdem der Python-Interpreter SystemExit abgefangen hat (z. B. ein Fehler beim Leeren gepufferter Daten in den Standard-Streams), wird der Exit-Status auf 120 geändert.

sys.flags¶

Das Benannte Tupel flags gibt den Status von Kommandozeilen-Flags an. Flags sollten nur nach Namen und nicht nach Index zugegriffen werden. Die Attribute sind schreibgeschützt.

flags.debug¶	`-d`
flags.inspect¶	`-i`
flags.interactive¶	`-i`
flags.isolated¶	`-I`
flags.optimize¶	`-O` oder `-OO`
flags.dont_write_bytecode¶	`-B`
flags.no_user_site¶	`-s`
flags.no_site¶	`-S`
flags.ignore_environment¶	`-E`
flags.verbose¶	`-v`
flags.bytes_warning¶	`-b`
flags.quiet¶	`-q`
flags.hash_randomization¶	`-R`
flags.dev_mode¶	`-X dev` (Python Entwicklermodus)
flags.utf8_mode¶	`-X utf8`
flags.safe_path¶	`-P`
flags.int_max_str_digits¶	`-X int_max_str_digits` (Begrenzung der Zeichenkettenkonvertierung für ganze Zahlen)
flags.warn_default_encoding¶	`-X warn_default_encoding`
flags.gil¶	`-X gil` und `PYTHON_GIL`
flags.thread_inherit_context¶	`-X thread_inherit_context` und `PYTHON_THREAD_INHERIT_CONTEXT`
flags.context_aware_warnings¶	`-X context_aware_warnings` und `PYTHON_CONTEXT_AWARE_WARNINGS`

Geändert in Version 3.2: Hinzugefügt wurde das Attribut quiet für das neue Flag -q.

Hinzugefügt in Version 3.2.3: Das Attribut hash_randomization.

Geändert in Version 3.3: Entferntes obsoletes Attribut division_warning.

Geändert in Version 3.4: Hinzugefügt wurde das Attribut isolated für das Flag -I isolated.

Geändert in Version 3.7: Hinzugefügt wurde das Attribut dev_mode für den neuen Python Entwicklermodus und das Attribut utf8_mode für das neue Flag -X utf8.

Geändert in Version 3.10: Hinzugefügt wurde das Attribut warn_default_encoding für das Flag -X warn_default_encoding.

Geändert in Version 3.11: Hinzugefügt wurde das Attribut safe_path für die Option -P.

Geändert in Version 3.11: Hinzugefügt wurde das Attribut int_max_str_digits.

Geändert in Version 3.13: Hinzugefügt wurde das Attribut gil.

Geändert in Version 3.14: Hinzugefügt wurde das Attribut thread_inherit_context.

Geändert in Version 3.14: Hinzugefügt wurde das Attribut context_aware_warnings.

sys.float_info¶

Ein Benanntes Tupel mit Informationen über den Gleitkommatyp. Es enthält Low-Level-Informationen über die Genauigkeit und die interne Darstellung. Die Werte entsprechen den verschiedenen Gleitkommakonstanten, die in der Standard-Headerdatei float.h für die Programmiersprache 'C' definiert sind; siehe Abschnitt 5.2.4.2.2 des ISO/IEC C-Standards von 1999 [C99], „Characteristics of floating types“, für Details.

Attribute des `float_info` Benannten Tupels¶
Attribut	float.h Makro	Erklärung
float_info.epsilon¶	`DBL_EPSILON`	Differenz zwischen 1.0 und dem kleinsten Wert größer als 1.0, der als Gleitkommazahl darstellbar ist. Siehe auch `math.ulp()`.
float_info.dig¶	`DBL_DIG`	Die maximale Anzahl von Dezimalstellen, die treu in einer Gleitkommazahl dargestellt werden können; siehe unten.
float_info.mant_dig¶	`DBL_MANT_DIG`	Gleitkomma-Genauigkeit: die Anzahl der Ziffern zur Basis `radix` im Mantissenbereich einer Gleitkommazahl.
float_info.max¶	`DBL_MAX`	Die maximal darstellbare positive endliche Gleitkommazahl.
float_info.max_exp¶	`DBL_MAX_EXP`	Die maximale Ganzzahl e, für die `radix**(e-1)` eine darstellbare endliche Gleitkommazahl ist.
float_info.max_10_exp¶	`DBL_MAX_10_EXP`	Die maximale Ganzzahl e, für die `10**e` im Bereich der darstellbaren endlichen Gleitkommazahlen liegt.
float_info.min¶	`DBL_MIN`	Die minimal darstellbare positive normierte Gleitkommazahl. Verwenden Sie `math.ulp(0.0)`, um die kleinste positive denormierte darstellbare Gleitkommazahl zu erhalten.
float_info.min_exp¶	`DBL_MIN_EXP`	Die minimale Ganzzahl e, für die `radix**(e-1)` eine normierte Gleitkommazahl ist.
float_info.min_10_exp¶	`DBL_MIN_10_EXP`	Die minimale Ganzzahl e, für die `10**e` eine normierte Gleitkommazahl ist.
float_info.radix¶	`FLT_RADIX`	Die Basis der Exponentendarstellung.
float_info.rounds¶	`FLT_ROUNDS`	Eine Ganzzahl, die den Rundungsmodus für die Gleitkommaarithmetik darstellt. Dies spiegelt den Wert des Systemmakros `FLT_ROUNDS` zum Zeitpunkt des Interpreterstarts wider. `-1`: nicht bestimmbar `0`: zur Null hin `1`: zur nächsten Zahl hin `2`: zu positiver Unendlichkeit hin `3`: zu negativer Unendlichkeit hin Alle anderen Werte für `FLT_ROUNDS` kennzeichnen implementierungsabhängiges Rundungsverhalten.

Das Attribut sys.float_info.dig bedarf weiterer Erläuterung. Wenn s eine Zeichenkette ist, die eine Dezimalzahl mit höchstens sys.float_info.dig signifikanten Ziffern darstellt, dann wird durch die Konvertierung von s in eine Gleitkommazahl und zurück wieder eine Zeichenkette gewonnen, die denselben Dezimalwert darstellt.

>>> import sys
>>> sys.float_info.dig
15
>>> s = '3.14159265358979'    # decimal string with 15 significant digits
>>> format(float(s), '.15g')  # convert to float and back -> same value
'3.14159265358979'

Für Zeichenketten mit mehr als sys.float_info.dig signifikanten Ziffern ist dies jedoch nicht immer der Fall.

>>> s = '9876543211234567'    # 16 significant digits is too many!
>>> format(float(s), '.16g')  # conversion changes value
'9876543211234568'

sys.float_repr_style¶: Ein String, der angibt, wie die Funktion repr() für Gleitkommazahlen funktioniert. Wenn der String den Wert 'short' hat, dann zielt repr(x) für eine endliche Gleitkommazahl x darauf ab, eine kurze Zeichenkette zu erzeugen, mit der Eigenschaft, dass float(repr(x)) == x gilt. Dies ist das übliche Verhalten in Python 3.1 und neuer. Andernfalls hat float_repr_style den Wert 'legacy' und repr(x) verhält sich genauso wie in Python-Versionen vor 3.1.

Hinzugefügt in Version 3.1.

sys.getallocatedblocks()¶

Gibt die Anzahl der vom Interpreter aktuell zugewiesenen Speicherblöcke zurück, unabhängig von ihrer Größe. Diese Funktion ist hauptsächlich nützlich für das Verfolgen und Debuggen von Speicherlecks. Aufgrund der internen Caches des Interpreters kann das Ergebnis von Aufruf zu Aufruf variieren; Sie müssen möglicherweise _clear_internal_caches() und gc.collect() aufrufen, um vorhersagbarere Ergebnisse zu erzielen.

Wenn ein Python-Build oder eine Implementierung diese Informationen nicht vernünftig berechnen kann, darf getallocatedblocks() stattdessen 0 zurückgeben.

Hinzugefügt in Version 3.4.

sys.getunicodeinternedsize()¶: Gibt die Anzahl der internierten Unicode-Objekte zurück.

Hinzugefügt in Version 3.12.

sys.getandroidapilevel()¶: Gibt die Build-Zeit-API-Ebene von Android als Ganzzahl zurück. Dies stellt die Mindestversion von Android dar, auf der dieser Python-Build ausgeführt werden kann. Laufzeitinformationsdaten finden Sie unter platform.android_ver().

Verfügbarkeit: Android.

Hinzugefügt in Version 3.7.

sys.getdefaultencoding()¶: Gibt 'utf-8' zurück. Dies ist der Name der Standard-Stringkodierung, die in Methoden wie str.encode() verwendet wird.

sys.getdlopenflags()¶: Gibt den aktuellen Wert der Flags zurück, die für dlopen()-Aufrufe verwendet werden. Symbolische Namen für die Flag-Werte finden Sie im Modul os (RTLD_xxx Konstanten, z. B. os.RTLD_LAZY).

Verfügbarkeit: Unix.

sys.getfilesystemencoding()¶

Ruft die Dateisystemkodierung ab: die Kodierung, die mit dem Dateisystem-Fehlerbehandlungsmechanismus zur Konvertierung zwischen Unicode-Dateinamen und Byte-Dateinamen verwendet wird. Der Dateisystem-Fehlerbehandlungsmechanismus wird von getfilesystemencodeerrors() zurückgegeben.

Für beste Kompatibilität sollten Dateinamen in allen Fällen als str verwendet werden, obwohl auch die Darstellung von Dateinamen als Bytes unterstützt wird. Funktionen, die Dateinamen akzeptieren oder zurückgeben, sollten entweder str oder bytes unterstützen und intern in die vom System bevorzugte Darstellung konvertieren.

os.fsencode() und os.fsdecode() sollten verwendet werden, um sicherzustellen, dass die korrekte Kodierung und der korrekte Fehlerbehandlungsmodus verwendet werden.

Die Dateisystemkodierung und der Fehlerbehandlungsmechanismus werden beim Python-Start von der Funktion PyConfig_Read() konfiguriert: siehe die Member filesystem_encoding und filesystem_errors von PyConfig.

Geändert in Version 3.2: Das Ergebnis von getfilesystemencoding() kann nicht mehr None sein.

Geändert in Version 3.6: Es wird nicht mehr garantiert, dass Windows 'mbcs' zurückgibt. Weitere Informationen finden Sie in PEP 529 und _enablelegacywindowsfsencoding().

Geändert in Version 3.7: Gibt 'utf-8' zurück, wenn der Python UTF-8-Modus aktiviert ist.

sys.getfilesystemencodeerrors()¶

Ruft den Fehlerbehandlungsmechanismus für Dateisystemkodierungen ab: den Fehlerbehandlungsmechanismus, der mit der Dateisystemkodierung verwendet wird, um zwischen Unicode-Dateinamen und Byte-Dateinamen zu konvertieren. Die Dateisystemkodierung wird von getfilesystemencoding() zurückgegeben.

os.fsencode() und os.fsdecode() sollten verwendet werden, um sicherzustellen, dass die korrekte Kodierung und der korrekte Fehlerbehandlungsmodus verwendet werden.

Die Dateisystemkodierung und der Fehlerbehandlungsmechanismus werden beim Python-Start von der Funktion PyConfig_Read() konfiguriert: siehe die Member filesystem_encoding und filesystem_errors von PyConfig.

Hinzugefügt in Version 3.6.

sys.get_int_max_str_digits()¶: Gibt den aktuellen Wert für die Begrenzung der Zeichenkettenkonvertierungslänge für Ganzzahlen zurück. Siehe auch set_int_max_str_digits().

Hinzugefügt in Version 3.11.

sys.getrefcount(object)¶

Gibt die Referenzanzahl des object zurück. Die zurückgegebene Anzahl ist im Allgemeinen um eins höher als erwartet, da sie die (temporäre) Referenz als Argument für getrefcount() enthält.

Beachten Sie, dass der zurückgegebene Wert möglicherweise nicht die tatsächliche Anzahl der Referenzen auf das Objekt widerspiegelt. Einige Objekte sind beispielsweise unsterblich und haben eine sehr hohe Referenzanzahl, die nicht der tatsächlichen Anzahl von Referenzen entspricht. Verlassen Sie sich daher nicht auf den zurückgegebenen Wert, es sei denn, es handelt sich um 0 oder 1.

CPython Implementierungsdetail: Unsterbliche Objekte mit einer hohen Referenzanzahl können über _is_immortal() identifiziert werden.

Geändert in Version 3.12: Unsterbliche Objekte haben sehr hohe Referenzzähler, die nicht der tatsächlichen Anzahl von Referenzen auf das Objekt entsprechen.

sys.getrecursionlimit()¶: Gibt den aktuellen Wert des Rekursionslimits zurück, der maximalen Tiefe des Python-Interpreter-Stacks. Dieses Limit verhindert, dass unendliche Rekursionen den C-Stack überlaufen und Python zum Absturz bringen. Es kann mit setrecursionlimit() gesetzt werden.

sys.getsizeof(object[, default])¶

Gibt die Größe eines Objekts in Bytes zurück. Das Objekt kann ein beliebiger Objekttyp sein. Alle eingebauten Objekte geben korrekte Ergebnisse zurück, aber dies muss nicht für Erweiterungen von Drittanbietern gelten, da es implementierungsspezifisch ist.

Nur der direkt dem Objekt zugerechnete Speicherverbrauch wird berücksichtigt, nicht der Speicherverbrauch von Objekten, auf die es verweist.

Wenn default angegeben ist, wird dieser zurückgegeben, wenn das Objekt keine Mittel zur Größenermittlung bereitstellt. Andernfalls wird ein TypeError ausgelöst.

getsizeof() ruft die `__sizeof__`-Methode des Objekts auf und fügt einen zusätzlichen Overhead für die Garbage Collection hinzu, wenn das Objekt von der Garbage Collection verwaltet wird.

Siehe recursive sizeof recipe für ein Beispiel für die rekursive Verwendung von getsizeof() zur Ermittlung der Größe von Containern und all ihrer Inhalte.

sys.getswitchinterval()¶: Gibt das „Thread-Umschaltintervall“ des Interpreters in Sekunden zurück; siehe setswitchinterval().

Hinzugefügt in Version 3.2.

sys._getframe([depth])¶

Gibt ein Frame-Objekt aus dem Aufrufstapel zurück. Wenn die optionale Ganzzahl depth angegeben ist, wird das Frame-Objekt zurückgegeben, das so viele Aufrufe unterhalb des oberen Endes des Stapels liegt. Wenn dies tiefer als der Aufrufstapel ist, wird ein ValueError ausgelöst. Der Standardwert für depth ist Null, wodurch der Frame am oberen Ende des Aufrufstapels zurückgegeben wird.

Löst ein Audit-Ereignis sys._getframe mit dem Argument frame aus.

CPython Implementierungsdetail: Diese Funktion sollte nur für interne und spezialisierte Zwecke verwendet werden. Es ist nicht garantiert, dass sie in allen Python-Implementierungen vorhanden ist.

sys._getframemodulename([depth])¶

Gibt den Namen eines Moduls aus dem Aufrufstapel zurück. Wenn die optionale Ganzzahl depth angegeben ist, wird das Modul zurückgegeben, das so viele Aufrufe unterhalb des oberen Endes des Stapels liegt. Wenn dies tiefer als der Aufrufstapel ist oder wenn das Modul nicht identifiziert werden kann, wird None zurückgegeben. Der Standardwert für depth ist Null, wodurch das Modul am oberen Ende des Aufrufstapels zurückgegeben wird.

Löst ein Audit-Ereignis sys._getframemodulename mit dem Argument depth aus.

CPython Implementierungsdetail: Diese Funktion sollte nur für interne und spezialisierte Zwecke verwendet werden. Es ist nicht garantiert, dass sie in allen Python-Implementierungen vorhanden ist.

Hinzugefügt in Version 3.12.

sys.getobjects(limit[, type])¶

Diese Funktion existiert nur, wenn CPython mit der spezialisierten Konfigurationsoption --with-trace-refs erstellt wurde. Sie ist nur zur Behebung von Problemen mit der Garbage Collection gedacht.

Gibt eine Liste von bis zu limit dynamisch zugewiesenen Python-Objekten zurück. Wenn type angegeben ist, werden nur Objekte dieses exakten Typs (nicht Untertypen) einbezogen.

Objekte aus der Liste sind nicht sicher zu verwenden. Insbesondere enthält das Ergebnis Objekte aus allen Interpretern, die ihren Objektzuweisungsstatus teilen (d. h. solche, die mit PyInterpreterConfig.use_main_obmalloc auf 1 gesetzt oder Py_NewInterpreter() verwenden, und der Hauptinterpreter). Das Mischen von Objekten aus verschiedenen Interpretern kann zu Abstürzen oder anderem unerwarteten Verhalten führen.

CPython Implementierungsdetail: Diese Funktion sollte nur für spezialisierte Zwecke verwendet werden. Es ist nicht garantiert, dass sie in allen Python-Implementierungen vorhanden ist.

Geändert in Version 3.14: Das Ergebnis kann Objekte aus anderen Interpretern enthalten.

sys.getprofile()¶: Ruft die Profilerfunktion ab, wie sie mit setprofile() gesetzt wurde.

sys.gettrace()¶: Ruft die Tracefunktion ab, wie sie mit settrace() gesetzt wurde.

CPython Implementierungsdetail: Die Funktion gettrace() ist nur zur Implementierung von Debuggern, Profilern, Abdeckungswerkzeugen und ähnlichem gedacht. Ihr Verhalten ist Teil der Implementierungsplattform und nicht Teil der Sprachdefinition, und daher möglicherweise nicht in allen Python-Implementierungen verfügbar.

sys.getwindowsversion()¶

Gibt ein benanntes Tupel zurück, das die aktuell laufende Windows-Version beschreibt. Die benannten Elemente sind major, minor, build, platform, service_pack, service_pack_minor, service_pack_major, suite_mask, product_type und platform_version. service_pack enthält einen String, platform_version ein 3-Tupel, und alle anderen Werte sind Ganzzahlen. Die Komponenten können auch nach Namen angesprochen werden, sodass sys.getwindowsversion()[0] äquivalent zu sys.getwindowsversion().major ist. Zur Kompatibilität mit früheren Versionen sind nur die ersten 5 Elemente über Indizierung abrufbar.

platform ist 2 (VER_PLATFORM_WIN32_NT).

product_type kann einer der folgenden Werte sein

Konstante	Bedeutung
`1` (VER_NT_WORKSTATION)	Das System ist eine Workstation.
`2` (VER_NT_DOMAIN_CONTROLLER)	Das System ist ein Domänencontroller.
`3` (VER_NT_SERVER)	Das System ist ein Server, aber kein Domänencontroller.

Diese Funktion kapselt die Win32-Funktion GetVersionEx(). Weitere Informationen zu diesen Feldern finden Sie in der Microsoft-Dokumentation zu OSVERSIONINFOEX().

platform_version gibt die Hauptversion, Nebenversion und Build-Nummer des aktuellen Betriebssystems zurück und nicht die Version, die für den Prozess emuliert wird. Sie ist für die Protokollierung gedacht und nicht für die Feature-Erkennung.

Hinweis

platform_version leitet die Version von kernel32.dll ab, die eine andere Version als die Betriebssystemversion haben kann. Bitte verwenden Sie das platform-Modul, um die genaue Betriebssystemversion zu erhalten.

Verfügbarkeit: Windows.

Geändert in Version 3.2: Geändert in ein benanntes Tupel und service_pack_minor, service_pack_major, suite_mask und product_type hinzugefügt.

Geändert in Version 3.6: platform_version hinzugefügt.

sys.get_asyncgen_hooks()¶: Gibt ein asyncgen_hooks-Objekt zurück, das einem namedtuple im Format (firstiter, finalizer) ähnelt, wobei firstiter und finalizer entweder None oder Funktionen sein sollen, die einen asynchronen Generator-Iterator als Argument nehmen und zur Planung der Finalisierung eines asynchronen Generators durch eine Ereignisschleife verwendet werden.

Hinzugefügt in Version 3.6: Weitere Einzelheiten finden Sie in PEP 525.

Hinweis

Diese Funktion wurde vorläufig hinzugefügt (weitere Einzelheiten finden Sie in PEP 411).

sys.get_coroutine_origin_tracking_depth()¶: Ruft die aktuelle Coroutine-Ursprungsverfolgungs-Tiefe ab, wie sie mit set_coroutine_origin_tracking_depth() gesetzt wurde.

Hinzugefügt in Version 3.7.

Hinweis

Diese Funktion wurde vorläufig hinzugefügt (weitere Einzelheiten finden Sie in PEP 411). Verwenden Sie sie nur zu Debugging-Zwecken.

sys.hash_info¶

Ein benanntes Tupel, das Informationen über die numerische Hash-Implementierung liefert. Weitere Einzelheiten zum Hashing numerischer Typen finden Sie unter Hashing numerischer Typen.

hash_info.width¶: Die Breite in Bits, die für Hash-Werte verwendet wird.

hash_info.modulus¶: Der Primmodul P, der für das numerische Hash-Schema verwendet wird.

hash_info.inf¶: Der Hash-Wert, der für eine positive Unendlichkeit zurückgegeben wird.

hash_info.nan¶: (Dieses Attribut wird nicht mehr verwendet)

hash_info.imag¶: Der Multiplikator, der für den imaginären Teil einer komplexen Zahl verwendet wird.

hash_info.algorithm¶: Der Name des Algorithmus für das Hashing von Zeichenketten, Bytes und Speicheransichten.

hash_info.hash_bits¶: Die interne Ausgabegröße des Hash-Algorithmus.

hash_info.seed_bits¶: Die Größe des Seed-Schlüssels des Hash-Algorithmus.

Hinzugefügt in Version 3.2.

Geändert in Version 3.4: algorithm, hash_bits und seed_bits hinzugefügt.

sys.hexversion¶

Die Versionsnummer, kodiert als einzelne Ganzzahl. Es ist garantiert, dass diese mit jeder Version ansteigt, einschließlich der korrekten Unterstützung für Nicht-Produktions-Releases. Um beispielsweise zu testen, ob der Python-Interpreter mindestens Version 1.5.2 hat, verwenden Sie

if sys.hexversion >= 0x010502F0:
    # use some advanced feature
    ...
else:
    # use an alternative implementation or warn the user
    ...

Dies wird hexversion genannt, da es nur dann sinnvoll erscheint, wenn es als Ergebnis der Übergabe an die eingebaute Funktion hex() betrachtet wird. Das benannte Tupel sys.version_info kann für eine menschenfreundlichere Kodierung derselben Informationen verwendet werden.

Weitere Einzelheiten zu hexversion finden Sie unter API und ABI-Versionierung.

sys.implementation¶

Ein Objekt, das Informationen über die Implementierung des derzeit laufenden Python-Interpreters enthält. Die folgenden Attribute müssen in allen Python-Implementierungen vorhanden sein.

name ist die Kennung der Implementierung, z. B. 'cpython'. Die tatsächliche Zeichenkette wird von der Python-Implementierung definiert, ist aber garantiert klein geschrieben.

version ist ein benanntes Tupel im gleichen Format wie sys.version_info. Es repräsentiert die Version der Python-Implementierung. Dies hat eine andere Bedeutung als die spezifische Version der Python-Sprache, der der derzeit laufende Interpreter entspricht, die sys.version_info darstellt. Zum Beispiel könnte für PyPy 1.8 sys.implementation.version sys.version_info(1, 8, 0, 'final', 0) sein, während sys.version_info sys.version_info(2, 7, 2, 'final', 0) wäre. Für CPython sind sie identisch, da es sich um die Referenzimplementierung handelt.

hexversion ist die Implementierungsversion im Hexadezimalformat, wie sys.hexversion.

cache_tag ist das Tag, das vom Importmechanismus in den Dateinamen von Cache-Modulen verwendet wird. Konventionsgemäß wäre es eine Kombination aus dem Namen und der Version der Implementierung, wie z. B. 'cpython-33'. Eine Python-Implementierung kann jedoch auch einen anderen Wert verwenden, wenn dies angemessen ist. Wenn cache_tag auf None gesetzt ist, bedeutet dies, dass das Modul-Caching deaktiviert werden sollte.

supports_isolated_interpreters ist ein boolescher Wert, der angibt, ob diese Implementierung mehrere isolierte Interpreter unterstützt. Für CPython ist dies auf den meisten Plattformen True. Plattformen mit dieser Unterstützung implementieren das Low-Level-Modul _interpreters.

Siehe auch

PEP 684, PEP 734 und concurrent.interpreters.

sys.implementation kann zusätzliche, implementierungsspezifische Attribute enthalten. Diese nicht standardmäßigen Attribute müssen mit einem Unterstrich beginnen und werden hier nicht beschrieben. Unabhängig von seinem Inhalt ändert sich sys.implementation während der Ausführung des Interpreters und zwischen Implementierungsversionen nicht. (Es kann sich jedoch zwischen Python-Sprachversionen ändern.) Weitere Informationen finden Sie in PEP 421.

Hinzugefügt in Version 3.3.

Geändert in Version 3.14: Das Feld supports_isolated_interpreters wurde hinzugefügt.

Hinweis

Die Hinzufügung neuer erforderlicher Attribute muss über den normalen PEP-Prozess erfolgen. Weitere Informationen finden Sie in PEP 421.

sys.int_info¶

Ein benanntes Tupel, das Informationen über die interne Darstellung von Ganzzahlen in Python enthält. Die Attribute sind schreibgeschützt.

int_info.bits_per_digit¶: Die Anzahl der Bits, die pro Ziffer gespeichert werden. Python-Ganzzahlen werden intern in Basis 2**int_info.bits_per_digit gespeichert.

int_info.sizeof_digit¶: Die Größe in Bytes des C-Typs, der zur Darstellung einer Ziffer verwendet wird.

int_info.default_max_str_digits¶: Der Standardwert für sys.get_int_max_str_digits(), wenn dieser nicht explizit konfiguriert ist.

int_info.str_digits_check_threshold¶: Der kleinste Nicht-Null-Wert für sys.set_int_max_str_digits(), PYTHONINTMAXSTRDIGITS oder -X int_max_str_digits.

Hinzugefügt in Version 3.1.

Geändert in Version 3.11: default_max_str_digits und str_digits_check_threshold hinzugefügt.

sys.__interactivehook__¶

Wenn dieses Attribut existiert, wird sein Wert automatisch (ohne Argumente) aufgerufen, wenn der Interpreter im interaktiven Modus gestartet wird. Dies geschieht, nachdem die Datei PYTHONSTARTUP gelesen wurde, sodass Sie diesen Hook dort festlegen können. Das Modul site richtet diesen ein.

Löst ein Audit-Ereignis cpython.run_interactivehook mit dem Hook-Objekt als Argument aus, wenn der Hook beim Start aufgerufen wird.

Hinzugefügt in Version 3.4.

sys.intern(string)¶

Fügt den string in die Tabelle der „internierten“ Zeichenketten ein und gibt die internierte Zeichenkette zurück – entweder die string selbst oder eine Kopie. Das Internieren von Zeichenketten ist nützlich, um eine kleine Leistungssteigerung bei der Dictionary-Suche zu erzielen. Wenn die Schlüssel in einem Dictionary interniert sind und der Suchschlüssel interniert ist, können die Schlüsselvergleiche (nach Hashing) durch einen Zeigervergleich anstelle eines Zeichenkettenvergleichs erfolgen. Normalerweise werden die in Python-Programmen verwendeten Namen automatisch interniert, und die Dictionaries, die zum Speichern von Modul-, Klassen- oder Instanzattributen verwendet werden, haben internierte Schlüssel.

Internierte Zeichenketten sind nicht unsterblich. Sie müssen eine Referenz auf den Rückgabewert von intern() behalten, um davon zu profitieren.

sys._is_gil_enabled()¶: Gibt True zurück, wenn die GIL aktiviert ist, und False, wenn sie deaktiviert ist.

Hinzugefügt in Version 3.13.

CPython Implementierungsdetail: Es ist nicht garantiert, dass sie in allen Python-Implementierungen vorhanden ist.

sys.is_finalizing()¶

Gibt True zurück, wenn der Haupt-Python-Interpreter heruntergefahren wird. Andernfalls wird False zurückgegeben.

Siehe auch die Ausnahme PythonFinalizationError.

Hinzugefügt in Version 3.5.

sys._jit¶

Dienstprogramme zur Beobachtung der Just-in-Time-Kompilierung.

CPython Implementierungsdetail: JIT-Kompilierung ist ein experimentelles Implementierungsdetail von CPython. sys._jit ist nicht garantiert vorhanden oder verhält sich in allen Python-Implementierungen, Versionen oder Build-Konfigurationen gleich.

Hinzugefügt in Version 3.14.

_jit.is_available()¶: Gibt True zurück, wenn die aktuelle Python-Ausführung JIT-Kompilierung unterstützt, andernfalls False. Dies kann durch das Kompilieren von CPython mit der Option --experimental-jit unter Windows und der Option --enable-experimental-jit auf allen anderen Plattformen gesteuert werden.

_jit.is_enabled()¶: Gibt True zurück, wenn die JIT-Kompilierung für den aktuellen Python-Prozess aktiviert ist (impliziert sys._jit.is_available()), andernfalls False. Wenn JIT-Kompilierung verfügbar ist, kann dies durch Setzen der Umgebungsvariable PYTHON_JIT auf 0 (deaktiviert) oder 1 (aktiviert) beim Interpreterstart gesteuert werden.

_jit.is_active()¶

Gibt True zurück, wenn der oberste Python-Frame gerade JIT-Code ausführt (impliziert sys._jit.is_enabled()), andernfalls False.

Hinweis

Diese Funktion ist für das Testen und Debuggen des JIT selbst gedacht. Sie sollte für keine anderen Zwecke verwendet werden.

Hinweis

Aufgrund der Natur von Tracing-JIT-Kompilierern können wiederholte Aufrufe dieser Funktion überraschende Ergebnisse liefern. Zum Beispiel führt die Verzweigung auf ihren Rückgabewert wahrscheinlich zu unerwartetem Verhalten (wenn dadurch JIT-Code ein- oder ausgetreten wird).

>>> for warmup in range(BIG_NUMBER):
...     # This line is "hot", and is eventually JIT-compiled:
...     if sys._jit.is_active():
...         # This line is "cold", and is run in the interpreter:
...         assert sys._jit.is_active()
...
Traceback (most recent call last):
  File "<stdin>", line 5, in <module>
    assert sys._jit.is_active()
           ~~~~~~~~~~~~~~~~~~^^
AssertionError

sys.last_exc¶: Diese Variable ist nicht immer definiert; sie wird auf die Ausnahmeinstanz gesetzt, wenn eine Ausnahme nicht behandelt wird und der Interpreter eine Fehlermeldung und einen Stack-Traceback ausgibt. Ihr beabsichtigter Verwendungszweck ist es, einem interaktiven Benutzer zu ermöglichen, ein Debugger-Modul zu importieren und eine Post-Mortem-Debugging-Sitzung durchzuführen, ohne den Befehl, der den Fehler verursacht hat, erneut ausführen zu müssen. (Typischerweise wird import pdb; pdb.pm() verwendet, um in den Post-Mortem-Debugger zu gelangen; siehe das Modul pdb für weitere Informationen.)

Hinzugefügt in Version 3.12.

sys._is_immortal(op)¶: Gibt True zurück, wenn das gegebene Objekt unsterblich ist, andernfalls False.

Hinweis

Objekte, die unsterblich sind (und daher bei Übergabe an diese Funktion True zurückgeben), sind nicht garantiert in zukünftigen Versionen unsterblich, und umgekehrt für sterbliche Objekte.

Hinzugefügt in Version 3.14.

CPython Implementierungsdetail: Diese Funktion sollte nur für spezialisierte Zwecke verwendet werden. Es ist nicht garantiert, dass sie in allen Python-Implementierungen vorhanden ist.

sys._is_interned(string)¶: Gibt True zurück, wenn der gegebene String "interned" ist, andernfalls False.

Hinzugefügt in Version 3.13.

CPython Implementierungsdetail: Es ist nicht garantiert, dass sie in allen Python-Implementierungen vorhanden ist.

sys.last_type¶
sys.last_value¶
sys.last_traceback¶: Diese drei Variablen sind veraltet; verwenden Sie stattdessen sys.last_exc. Sie enthalten die Legacy-Darstellung von sys.last_exc, wie sie von exc_info() oben zurückgegeben wird.

sys.maxsize¶: Eine Ganzzahl, die den Maximalwert angibt, den eine Variable vom Typ Py_ssize_t annehmen kann. Dies ist normalerweise 2**31 - 1 auf einer 32-Bit-Plattform und 2**63 - 1 auf einer 64-Bit-Plattform.

sys.maxunicode¶: Eine Ganzzahl, die den Wert des größten Unicode-Codepunkts angibt, d.h. 1114111 (0x10FFFF in Hexadezimal).

Geändert in Version 3.3: Vor PEP 393 war sys.maxunicode entweder 0xFFFF oder 0x10FFFF, abhängig von der Konfigurationsoption, die angab, ob Unicode-Zeichen als UCS-2 oder UCS-4 gespeichert wurden.

sys.meta_path¶

Eine Liste von Meta-Path-Finder-Objekten, deren find_spec()-Methoden aufgerufen werden, um zu prüfen, ob eines der Objekte das zu importierende Modul finden kann. Standardmäßig enthält sie Einträge, die die Standard-Importsemantik von Python implementieren. Die Methode find_spec() wird mit mindestens dem absoluten Namen des zu importierenden Moduls aufgerufen. Wenn das zu importierende Modul in einem Paket enthalten ist, wird das __path__-Attribut des übergeordneten Pakets als zweites Argument übergeben. Die Methode gibt eine Modulspezifikation zurück oder None, wenn das Modul nicht gefunden werden kann.

Siehe auch

importlib.abc.MetaPathFinder: Die abstrakte Basisklasse, die die Schnittstelle von Finder-Objekten auf meta_path definiert.
importlib.machinery.ModuleSpec: Die konkrete Klasse, von der find_spec() Instanzen zurückgeben sollte.

Geändert in Version 3.4: Modulspezifikationen wurden in Python 3.4 durch PEP 451 eingeführt.

Geändert in Version 3.12: Das Fallback, das nach einer find_module()-Methode suchte, wenn ein meta_path-Eintrag keine find_spec()-Methode hatte, wurde entfernt.

sys.modules¶: Dies ist ein Dictionary, das Modulnamen auf bereits geladene Module abbildet. Dies kann manipuliert werden, um das Neuladen von Modulen und andere Tricks zu erzwingen. Das Ersetzen des Dictionaries wird jedoch nicht unbedingt wie erwartet funktionieren und das Löschen wesentlicher Elemente aus dem Dictionary kann dazu führen, dass Python abstürzt. Wenn Sie über dieses globale Dictionary iterieren möchten, verwenden Sie immer sys.modules.copy() oder tuple(sys.modules), um Ausnahmen zu vermeiden, da seine Größe als Nebeneffekt von Code oder Aktivitäten in anderen Threads während der Iteration wachsen kann.

sys.orig_argv¶

Die Liste der ursprünglichen Kommandozeilenargumente, die an die Python-Ausführungsdatei übergeben wurden.

Die Elemente von sys.orig_argv sind die Argumente für den Python-Interpreter, während die Elemente von sys.argv die Argumente für das Programm des Benutzers sind. Vom Interpreter selbst verbrauchte Argumente sind in sys.orig_argv vorhanden und fehlen in sys.argv.

Hinzugefügt in Version 3.10.

sys.path¶

Eine Liste von Zeichenketten, die den Suchpfad für Module angibt. Initialisiert aus der Umgebungsvariable PYTHONPATH, plus ein installationsabhängiger Standardwert.

Standardmäßig, wie beim Programmstart initialisiert, wird ein potenziell unsicherer Pfad vor sys.path eingefügt (bevor die Einträge eingefügt werden, die sich aus PYTHONPATH ergeben).

python -m module Kommandozeile: das aktuelle Arbeitsverzeichnis voranstellen.
python script.py Kommandozeile: das Verzeichnis des Skripts voranstellen. Wenn es sich um einen symbolischen Link handelt, symbolische Links auflösen.
python -c code und python (REPL) Kommandozeilen: eine leere Zeichenkette voranstellen, was das aktuelle Arbeitsverzeichnis bedeutet.

Um diesen potenziell unsicheren Pfad nicht voranzustellen, verwenden Sie die Kommandozeilenoption -P oder die Umgebungsvariable PYTHONSAFEPATH.

Ein Programm ist frei, diese Liste für eigene Zwecke zu ändern. Nur Zeichenketten sollten zu sys.path hinzugefügt werden; alle anderen Datentypen werden beim Import ignoriert.

Siehe auch

Modul site Hier wird beschrieben, wie .pth-Dateien zum Erweitern von sys.path verwendet werden.

sys.path_hooks¶

Eine Liste von aufrufbaren Objekten, die ein Pfadargument entgegennehmen, um zu versuchen, einen Finder für diesen Pfad zu erstellen. Wenn ein Finder erstellt werden kann, sollte er vom aufrufbaren Objekt zurückgegeben werden, andernfalls wird ImportError ausgelöst.

Ursprünglich spezifiziert in PEP 302.

sys.path_importer_cache¶

Ein Dictionary, das als Cache für Finder-Objekte dient. Die Schlüssel sind Pfade, die an sys.path_hooks übergeben wurden, und die Werte sind die gefundenen Finder. Wenn ein Pfad ein gültiger Dateisystempfad ist, aber kein Finder auf sys.path_hooks gefunden wird, wird None gespeichert.

Ursprünglich spezifiziert in PEP 302.

sys.platform¶

Eine Zeichenkette, die einen Plattformidentifikator enthält. Bekannte Werte sind

System	`platform` Wert
AIX	`'aix'`
Android	`'android'`
Emscripten	`'emscripten'`
FreeBSD	`'freebsd'`
iOS	`'ios'`
Linux	`'linux'`
macOS	`'darwin'`
Windows	`'win32'`
Windows/Cygwin	`'cygwin'`
WASI	`'wasi'`

Auf Unix-Systemen, die nicht in der Tabelle aufgeführt sind, ist der Wert der klein geschriebene OS-Name, wie er von uname -s zurückgegeben wird, mit dem ersten Teil der Version, wie sie von uname -r zurückgegeben wird, angehängt, z.B. 'sunos5', zum Zeitpunkt der Erstellung von Python. Sofern Sie nicht nach einer spezifischen Systemversion testen möchten, wird daher die folgende Idiomatik empfohlen

if sys.platform.startswith('sunos'):
    # SunOS-specific code here...

Geändert in Version 3.3: Unter Linux enthält sys.platform nicht mehr die Hauptversion. Es ist immer 'linux' anstatt 'linux2' oder 'linux3'.

Geändert in Version 3.8: Auf AIX enthält sys.platform nicht mehr die Hauptversion. Es ist immer 'aix' anstatt 'aix5' oder 'aix7'.

Geändert in Version 3.13: Unter Android gibt sys.platform nun 'android' anstelle von 'linux' zurück.

Geändert in Version 3.14: Auf FreeBSD enthält sys.platform nicht mehr die Hauptversion. Es ist immer 'freebsd' anstatt 'freebsd13' oder 'freebsd14'.

Siehe auch

os.name hat eine gröbere Granularität. os.uname() liefert systemabhängige Versionsinformationen.

Das Modul platform bietet detaillierte Prüfungen für die Identität des Systems.

sys.platlibdir¶

Name des plattformspezifischen Bibliotheksverzeichnisses. Er wird zum Aufbau des Pfads für die Standardbibliothek und der Pfade für installierte Erweiterungsmodule verwendet.

Er ist auf den meisten Plattformen gleich "lib". Auf Fedora und SuSE ist er auf 64-Bit-Plattformen gleich "lib64", was zu den folgenden sys.path-Pfaden führt (wobei X.Y die Python major.minor-Version ist)

/usr/lib64/pythonX.Y/: Standardbibliothek (wie os.py aus dem Modul os)
/usr/lib64/pythonX.Y/lib-dynload/: C-Erweiterungsmodule der Standardbibliothek (wie das Modul errno, der genaue Dateiname ist plattformspezifisch)
/usr/lib/pythonX.Y/site-packages/ (immer lib verwenden, nicht sys.platlibdir): Drittanbieter-Module
/usr/lib64/pythonX.Y/site-packages/: C-Erweiterungsmodule von Drittanbieterpaketen

Hinzugefügt in Version 3.9.

sys.prefix¶: Eine Zeichenkette, die das standortspezifische Verzeichnispräfix angibt, in dem die plattformunabhängigen Python-Dateien installiert sind; unter Unix ist der Standardwert /usr/local. Dies kann zur Build-Zeit mit dem Argument --prefix für das Skript configure gesetzt werden. Siehe Installationspfade für abgeleitete Pfade.

Hinweis

Wenn eine virtuelle Umgebung aktiv ist, zeigt dieser prefix auf die virtuelle Umgebung. Der Wert für die Python-Installation ist weiterhin über base_prefix verfügbar. Weitere Informationen finden Sie unter Virtuelle Umgebungen.

Geändert in Version 3.14: Bei Ausführung in einer virtuellen Umgebung zeigen prefix und exec_prefix nun auf das Präfix der virtuellen Umgebung, anstatt auf site. Dies geschieht durch die Pfadinitialisierung. Das bedeutet, dass prefix und exec_prefix immer auf die virtuelle Umgebung zeigen, auch wenn site deaktiviert ist (-S).

sys.ps1¶
sys.ps2¶: Zeichenketten, die die primäre und sekundäre Eingabeaufforderung des Interpreters spezifizieren. Diese sind nur definiert, wenn der Interpreter im interaktiven Modus läuft. Ihre anfänglichen Werte sind in diesem Fall '>>> ' und '... '. Wenn ein Objekt, das keine Zeichenkette ist, einer der Variablen zugewiesen wird, wird seine str()-Darstellung jedes Mal neu ausgewertet, wenn der Interpreter eine neue interaktive Anweisung liest; dies kann zur Implementierung einer dynamischen Eingabeaufforderung verwendet werden.

sys.setdlopenflags(n)¶: Setzt die Flags, die der Interpreter für dlopen()-Aufrufe verwendet, z.B. wenn der Interpreter Erweiterungsmodule lädt. Unter anderem aktiviert dies eine späte Auflösung von Symbolen beim Importieren eines Moduls, wenn es als sys.setdlopenflags(0) aufgerufen wird. Um Symbole zwischen Erweiterungsmodulen zu teilen, rufen Sie es als sys.setdlopenflags(os.RTLD_GLOBAL) auf. Symbolische Namen für die Flag-Werte finden Sie im Modul os (RTLD_xxx-Konstanten, z.B. os.RTLD_LAZY).

Verfügbarkeit: Unix.

sys.set_int_max_str_digits(maxdigits)¶: Legt die Beschränkung der String-Konvertierungslänge für Ganzzahlen fest, die von diesem Interpreter verwendet wird. Siehe auch get_int_max_str_digits().

Hinzugefügt in Version 3.11.

sys.setprofile(profilefunc)¶

Setzt die Profilfunktion des Systems, mit der Sie einen Python-Quellcode-Profiler in Python implementieren können. Siehe Kapitel Die Python-Profiler für weitere Informationen zum Python-Profiler. Die Profilfunktion des Systems wird ähnlich wie die Tracing-Funktion des Systems aufgerufen (siehe settrace()), aber sie wird mit unterschiedlichen Ereignissen aufgerufen, z.B. wird sie nicht für jede ausgeführte Codezeile aufgerufen (nur bei Aufruf und Rückkehr, aber das Rückgabeereignis wird auch gemeldet, wenn eine Ausnahme gesetzt wurde). Die Funktion ist threadspezifisch, aber es gibt keine Möglichkeit für den Profiler, Kontextwechsel zwischen Threads zu erkennen, daher macht es keinen Sinn, sie im Beisein mehrerer Threads zu verwenden. Außerdem wird ihr Rückgabewert nicht verwendet, daher kann sie einfach None zurückgeben. Fehler in der Profilfunktion führen dazu, dass sie selbst unset wird.

Hinweis

Der gleiche Tracing-Mechanismus wird für setprofile() wie für settrace() verwendet. Um Aufrufe mit setprofile() innerhalb einer Tracing-Funktion (z.B. in einem Debugger-Breakpoint) zu tracen, siehe call_tracing().

Profilfunktionen sollten drei Argumente haben: frame, event und arg. frame ist der aktuelle Stack-Frame. event ist eine Zeichenkette: 'call', 'return', 'c_call', 'c_return' oder 'c_exception'. arg hängt vom Ereignistyp ab.

Die Ereignisse haben folgende Bedeutung

'call': Eine Funktion wird aufgerufen (oder ein anderer Codeblock betreten). Die Profilfunktion wird aufgerufen; arg ist None.
'return': Eine Funktion (oder ein anderer Codeblock) wird gleich zurückkehren. Die Profilfunktion wird aufgerufen; arg ist der Wert, der zurückgegeben wird, oder None, wenn das Ereignis durch das Auslösen einer Ausnahme verursacht wird.
'c_call': Eine C-Funktion wird aufgerufen. Dies kann eine Erweiterungsfunktion oder eine eingebaute Funktion sein. arg ist das C-Funktionsobjekt.
'c_return': Eine C-Funktion ist zurückgekehrt. arg ist das C-Funktionsobjekt.
'c_exception': Eine C-Funktion hat eine Ausnahme ausgelöst. arg ist das C-Funktionsobjekt.

Löst ein Audit-Ereignis sys.setprofile ohne Argumente aus.

sys.setrecursionlimit(limit)¶

Setzt die maximale Tiefe des Python-Interpreter-Stacks auf limit. Dieses Limit verhindert, dass unendliche Rekursionen zu einem Überlauf des C-Stacks führen und Python zum Absturz bringen.

Das höchstmögliche Limit ist plattformabhängig. Ein Benutzer muss möglicherweise das Limit erhöhen, wenn er ein Programm hat, das tiefe Rekursion erfordert und eine Plattform, die ein höheres Limit unterstützt. Dies sollte mit Vorsicht geschehen, da ein zu hohes Limit zu einem Absturz führen kann.

Wenn das neue Limit bei der aktuellen Rekursionstiefe zu niedrig ist, wird eine RecursionError-Ausnahme ausgelöst.

Geändert in Version 3.5.1: Eine RecursionError-Ausnahme wird jetzt ausgelöst, wenn das neue Limit bei der aktuellen Rekursionstiefe zu niedrig ist.

sys.setswitchinterval(interval)¶: Setzt das Thread-Switching-Intervall des Interpreters (in Sekunden). Dieser Fließkommawert bestimmt die ideale Dauer der "Zeitschlitze", die gleichzeitig laufenden Python-Threads zugewiesen werden. Bitte beachten Sie, dass der tatsächliche Wert höher sein kann, insbesondere wenn lang laufende interne Funktionen oder Methoden verwendet werden. Außerdem ist es die Entscheidung des Betriebssystems, welcher Thread am Ende des Intervalls geplant wird. Der Interpreter hat keinen eigenen Scheduler.

Hinzugefügt in Version 3.2.

sys.settrace(tracefunc)¶

Setzt die Tracing-Funktion des Systems, mit der Sie einen Python-Quellcode-Debugger in Python implementieren können. Die Funktion ist threadspezifisch; damit ein Debugger mehrere Threads unterstützt, muss er eine Tracing-Funktion mit settrace() für jeden zu debuggenden Thread registrieren oder threading.settrace() verwenden.

Tracing-Funktionen sollten drei Argumente haben: frame, event und arg. frame ist der aktuelle Stack-Frame. event ist eine Zeichenkette: 'call', 'line', 'return', 'exception' oder 'opcode'. arg hängt vom Ereignistyp ab.

Die Trace-Funktion wird aufgerufen (mit event auf 'call' gesetzt), wenn ein neuer lokaler Gültigkeitsbereich betreten wird; sie sollte eine Referenz auf eine lokale Trace-Funktion für den neuen Gültigkeitsbereich zurückgeben oder None, wenn der Gültigkeitsbereich nicht verfolgt werden soll.

Die lokale Trace-Funktion sollte eine Referenz auf sich selbst zurückgeben oder auf eine andere Funktion, die dann als lokale Trace-Funktion für den Gültigkeitsbereich verwendet wird.

Wenn in der Trace-Funktion ein Fehler auftritt, wird sie wie durch den Aufruf von settrace(None) unset.

Hinweis

Das Tracing ist während des Aufrufs der Trace-Funktion deaktiviert (z.B. eine Funktion, die von settrace() gesetzt wurde). Für rekursives Tracing siehe call_tracing().

Die Ereignisse haben folgende Bedeutung

'call': Eine Funktion wird aufgerufen (oder ein anderer Codeblock betreten). Die globale Trace-Funktion wird aufgerufen; arg ist None; der Rückgabewert bestimmt die lokale Trace-Funktion.
'line': Der Interpreter ist dabei, eine neue Codezeile auszuführen oder die Bedingung einer Schleife erneut auszuführen. Die lokale Trace-Funktion wird aufgerufen; arg ist None; der Rückgabewert bestimmt die neue lokale Trace-Funktion. Siehe Objects/lnotab_notes.txt für eine detaillierte Erklärung, wie dies funktioniert. Zeilenbezogene Ereignisse können für einen Frame deaktiviert werden, indem f_trace_lines auf False für diesen Frame gesetzt wird.
'return': Eine Funktion (oder ein anderer Codeblock) wird zurückgegeben. Die lokale Trace-Funktion wird aufgerufen; arg ist der Wert, der zurückgegeben wird, oder None, wenn das Ereignis durch Auslösen einer Ausnahme verursacht wird. Der Rückgabewert der Trace-Funktion wird ignoriert.
'exception': Eine Ausnahme ist aufgetreten. Die lokale Trace-Funktion wird aufgerufen; arg ist ein Tupel (exception, value, traceback); der Rückgabewert bestimmt die neue lokale Trace-Funktion.
'opcode': Der Interpreter ist dabei, einen neuen Opcode auszuführen (siehe dis für Opcode-Details). Die lokale Trace-Funktion wird aufgerufen; arg ist None; der Rückgabewert bestimmt die neue lokale Trace-Funktion. Opcode-bezogene Ereignisse werden standardmäßig nicht ausgelöst: sie müssen explizit angefordert werden, indem f_trace_opcodes auf True für den Frame gesetzt wird.

Beachten Sie, dass bei der Weitergabe einer Ausnahme durch die Kette von Aufrufern ein 'exception'-Ereignis auf jeder Ebene generiert wird.

Für eine feinere Steuerung ist es möglich, eine Trace-Funktion festzulegen, indem frame.f_trace = tracefunc explizit zugewiesen wird, anstatt sich darauf zu verlassen, dass sie indirekt über den Rückgabewert einer bereits installierten Trace-Funktion gesetzt wird. Dies ist auch erforderlich, um die Trace-Funktion für den aktuellen Frame zu aktivieren, was settrace() nicht tut. Beachten Sie, dass dafür eine globale Trace-Funktion mit settrace() installiert worden sein muss, um die Laufzeit-Tracing-Maschinerie zu aktivieren, aber es muss nicht dieselbe Trace-Funktion sein (z.B. könnte es sich um eine performante Trace-Funktion handeln, die einfach None zurückgibt, um sich auf jedem Frame sofort zu deaktivieren).

Weitere Informationen zu Code- und Frame-Objekten finden Sie unter Die Standardtyp-Hierarchie.

Löst ein Audit-Ereignis sys.settrace ohne Argumente aus.

CPython-Implementierungsdetail: Die Funktion settrace() ist nur zur Implementierung von Debuggern, Profilern, Abdeckungswerkzeugen und Ähnlichem bestimmt. Ihr Verhalten ist Teil der Implementierungsplattform und nicht Teil der Sprachdefinition, und daher möglicherweise nicht in allen Python-Implementierungen verfügbar.

Geändert in Version 3.7: Der Ereignistyp 'opcode' wurde hinzugefügt; die Attribute f_trace_lines und f_trace_opcodes wurden zu Frames hinzugefügt

sys.set_asyncgen_hooks([firstiter] [, finalizer])¶

Akzeptiert zwei optionale Schlüsselwortargumente, die aufrufbare Objekte sind und einen asynchronen Generator-Iterator als Argument entgegennehmen. Das firstiter-Callable wird aufgerufen, wenn ein asynchroner Generator zum ersten Mal iteriert wird. Der finalizer wird aufgerufen, wenn ein asynchroner Generator zur Garbage Collection ansteht.

Löst ein Audit-Ereignis sys.set_asyncgen_hooks_firstiter ohne Argumente aus.

Löst ein Audit-Ereignis sys.set_asyncgen_hooks_finalizer ohne Argumente aus.

Zwei Audit-Ereignisse werden ausgelöst, da die zugrundeliegende API aus zwei Aufrufen besteht, von denen jeder sein eigenes Ereignis auslösen muss.

Hinzugefügt in Version 3.6: Siehe PEP 525 für weitere Details und ein Referenzbeispiel für eine finalizer-Methode finden Sie in der Implementierung von asyncio.Loop.shutdown_asyncgens in Lib/asyncio/base_events.py

Hinweis

Diese Funktion wurde provisorisch hinzugefügt (siehe PEP 411 für Details.)

sys.set_coroutine_origin_tracking_depth(depth)¶

Ermöglicht die Aktivierung oder Deaktivierung der Verfolgung des Ursprungs von Coroutinen. Wenn aktiviert, enthält das Attribut cr_origin auf Coroutine-Objekten ein Tupel von (Dateiname, Zeilennummer, Funktionsname)-Tupeln, die den Traceback beschreiben, wo das Coroutine-Objekt erstellt wurde, mit dem aktuellsten Aufruf zuerst. Wenn deaktiviert, ist cr_origin None.

Um zu aktivieren, übergeben Sie einen depth-Wert größer als Null; dies bestimmt die Anzahl der Frames, deren Informationen erfasst werden. Um zu deaktivieren, setzen Sie depth auf Null.

Diese Einstellung ist threadspezifisch.

Hinzugefügt in Version 3.7.

Hinweis

Diese Funktion wurde provisorisch hinzugefügt (siehe PEP 411 für Details.) Verwenden Sie sie nur zu Debugging-Zwecken.

sys.activate_stack_trampoline(backend, /)¶

Aktiviert das Stack-Profiler-Trampolin-backend. Das einzige unterstützte Backend ist "perf".

Stack-Trampoline können nicht aktiviert werden, wenn die JIT aktiv ist.

Verfügbarkeit: Linux.

Hinzugefügt in Version 3.12.

Siehe auch

sys.deactivate_stack_trampoline()¶

Deaktiviert das aktuelle Stack-Profiler-Trampolin-Backend.

Wenn kein Stack-Profiler aktiviert ist, hat diese Funktion keine Auswirkung.

Verfügbarkeit: Linux.

Hinzugefügt in Version 3.12.

sys.is_stack_trampoline_active()¶: Gibt True zurück, wenn ein Stack-Profiler-Trampolin aktiv ist.

Verfügbarkeit: Linux.

Hinzugefügt in Version 3.12.

sys.remote_exec(pid, script)¶

Führt script, eine Datei mit Python-Code, im entfernten Prozess mit der angegebenen pid aus.

Diese Funktion kehrt sofort zurück, und der Code wird vom Hauptthread des Zielprozesses bei der nächsten Gelegenheit ausgeführt, ähnlich wie Signale behandelt werden. Es gibt keine Schnittstelle, um festzustellen, wann der Code ausgeführt wurde. Der Aufrufer ist dafür verantwortlich, sicherzustellen, dass die Datei existiert, wenn der entfernte Prozess versucht, sie zu lesen, und dass sie nicht überschrieben wurde.

Der entfernte Prozess muss einen CPython-Interpreter der gleichen Haupt- und Nebenversion wie der lokale Prozess ausführen. Wenn entweder der lokale oder der entfernte Interpreter eine Vorabversion (Alpha, Beta oder Release Candidate) ist, müssen die lokalen und entfernten Interpreter genau die gleiche Version sein.

Wenn der Code im entfernten Prozess ausgeführt wird, wird ein Audit-Ereignis sys.remote_exec mit der pid und dem Pfad zur Skriptdatei ausgelöst. Dieses Ereignis wird in dem Prozess ausgelöst, der sys.remote_exec() aufgerufen hat.

Wenn das Skript im entfernten Prozess ausgeführt wird, wird ein Audit-Ereignis cpython.remote_debugger_script mit dem Pfad im entfernten Prozess ausgelöst. Dieses Ereignis wird im entfernten Prozess ausgelöst, nicht in dem, der sys.remote_exec() aufgerufen hat.

Verfügbarkeit: Unix, Windows.

Hinzugefügt in Version 3.14.

sys._enablelegacywindowsfsencoding()¶

Ändert die Dateisystem-Codierung und Fehlerbehandlung zu 'mbcs' bzw. 'replace', um die Konsistenz mit Versionen von Python vor 3.6 zu gewährleisten.

Dies ist äquivalent zur Definition der Umgebungsvariable PYTHONLEGACYWINDOWSFSENCODING vor dem Start von Python.

Siehe auch sys.getfilesystemencoding() und sys.getfilesystemencodeerrors().

Verfügbarkeit: Windows.

Hinweis

Das Ändern der Dateisystem-Codierung nach dem Python-Start ist riskant, da die alte fsencoding oder von der alten fsencoding codierte Pfade möglicherweise irgendwo zwischengespeichert werden. Verwenden Sie stattdessen PYTHONLEGACYWINDOWSFSENCODING.

Hinzugefügt in Version 3.6: Siehe PEP 529 für weitere Details.

Veraltet seit Version 3.13, wird in Version 3.16 entfernt: Verwenden Sie stattdessen PYTHONLEGACYWINDOWSFSENCODING.

sys.stdin¶

sys.stdout¶

sys.stderr¶

Datei-Objekte, die vom Interpreter für Standardeingabe, -ausgabe und -fehler verwendet werden.

stdin wird für alle interaktiven Eingaben verwendet (einschließlich Aufrufen von input());
stdout wird für die Ausgabe von print() und Ausdrucks-Anweisungen und für die Eingabeaufforderungen von input() verwendet;
Die eigenen Eingabeaufforderungen des Interpreters und seine Fehlermeldungen gehen an stderr.

Diese Streams sind reguläre Textdateien, wie sie von der Funktion open() zurückgegeben werden. Ihre Parameter werden wie folgt gewählt:

Die Codierung und Fehlerbehandlung werden von PyConfig.stdio_encoding und PyConfig.stdio_errors initialisiert.

Unter Windows wird UTF-8 für das Konsolengerät verwendet. Nicht-Zeichengeräte wie Festplattendateien und Pipes verwenden die System-Locale-Codierung (d.h. die ANSI-Codepage). Nicht-Konsolen-Zeichengeräte wie NUL (d.h. wo isatty() True zurückgibt) verwenden den Wert der Konsolen-Eingabe- und Ausgabecodepages beim Start, für stdin bzw. stdout/stderr. Dies ist standardmäßig die System-Locale-Codierung, wenn der Prozess nicht initial mit einer Konsole verbunden ist.

Das spezielle Verhalten der Konsole kann durch Setzen der Umgebungsvariable PYTHONLEGACYWINDOWSSTDIO vor dem Start von Python überschrieben werden. In diesem Fall werden die Konsolen-Codepages wie bei jedem anderen Zeichengerät verwendet.

Unter allen Plattformen können Sie die Zeichencodierung überschreiben, indem Sie die Umgebungsvariable PYTHONIOENCODING vor dem Start von Python setzen oder die neue Kommandozeilenoption -X utf8 und die Umgebungsvariable PYTHONUTF8 verwenden. Für die Windows-Konsole gilt dies jedoch nur, wenn auch PYTHONLEGACYWINDOWSSTDIO gesetzt ist.
Im interaktiven Modus ist der stdout-Stream zeilenweise gepuffert. Andernfalls ist er blockweise gepuffert wie reguläre Textdateien. Der stderr-Stream ist in beiden Fällen zeilenweise gepuffert. Sie können beide Streams unbuffered machen, indem Sie die Kommandozeilenoption -u übergeben oder die Umgebungsvariable PYTHONUNBUFFERED setzen.

Geändert in Version 3.9: Nicht-interaktives stderr ist jetzt zeilenweise gepuffert statt vollständig gepuffert.

Hinweis

Um Binärdaten von/zu den Standard-Streams zu schreiben oder zu lesen, verwenden Sie das zugrundeliegende binäre buffer-Objekt. Um beispielsweise Bytes nach stdout zu schreiben, verwenden Sie sys.stdout.buffer.write(b'abc').

Wenn Sie jedoch eine Bibliothek schreiben (und nicht kontrollieren, in welchem Kontext ihr Code ausgeführt wird), beachten Sie, dass die Standard-Streams durch dateiähnliche Objekte wie io.StringIO ersetzt werden können, die das Attribut buffer nicht unterstützen.

sys.__stdin__¶

sys.__stdout__¶

sys.__stderr__¶

Diese Objekte enthalten die ursprünglichen Werte von stdin, stderr und stdout zu Beginn des Programms. Sie werden während der Finalisierung verwendet und könnten nützlich sein, um auf den tatsächlichen Standard-Stream zu schreiben, unabhängig davon, ob das sys.std*-Objekt umgeleitet wurde.

Es kann auch verwendet werden, um die tatsächlichen Dateien wieder auf bekannte funktionierende Datei-Objekte wiederherzustellen, falls sie durch ein fehlerhaftes Objekt überschrieben wurden. Der bevorzugte Weg dazu ist jedoch, den vorherigen Stream explizit zu speichern, bevor er ersetzt wird, und das gespeicherte Objekt wiederherzustellen.

Hinweis

Unter bestimmten Bedingungen können stdin, stdout und stderr sowie die ursprünglichen Werte __stdin__, __stdout__ und __stderr__ None sein. Dies ist normalerweise bei Windows GUI-Apps der Fall, die nicht mit einer Konsole verbunden sind, und bei Python-Apps, die mit pythonw gestartet wurden.

sys.stdlib_module_names¶

Ein frozenset von Strings, das die Namen von Standardbibliotheksmodulen enthält.

Es ist auf allen Plattformen gleich. Module, die auf einigen Plattformen nicht verfügbar sind und Module, die beim Erstellen von Python deaktiviert wurden, werden ebenfalls aufgeführt. Alle Modularten werden aufgelistet: reine Python-Module, eingebaute, eingefrorene und Erweiterungsmodule. Testmodule sind ausgeschlossen.

Für Pakete wird nur das Hauptpaket aufgeführt: Unterpakete und Untermodule werden nicht aufgeführt. Zum Beispiel wird das Paket email aufgeführt, aber das Unterpaket email.mime und das Untermodul email.message werden nicht aufgeführt.

Siehe auch die Liste sys.builtin_module_names.

Hinzugefügt in Version 3.10.

sys.thread_info¶

Ein Benanntes Tupel mit Informationen über die Thread-Implementierung.

thread_info.name¶

Der Name der Thread-Implementierung

"nt": Windows-Threads
"pthread": POSIX-Threads
"pthread-stubs": Stub POSIX-Threads (auf WebAssembly-Plattformen ohne Threading-Unterstützung)
"solaris": Solaris-Threads

thread_info.lock¶

Der Name der Lock-Implementierung

"semaphore": Ein Lock verwendet ein Semaphor
"mutex+cond": Ein Lock verwendet eine Mutex und eine Bedingungsvariable
None, wenn diese Information unbekannt ist

thread_info.version¶: Der Name und die Version der Thread-Bibliothek. Es ist ein String oder None, wenn diese Information unbekannt ist.

Hinzugefügt in Version 3.3.

sys.tracebacklimit¶: Wenn diese Variable auf einen ganzzahligen Wert gesetzt ist, bestimmt sie die maximale Anzahl von Traceback-Informationsebenen, die bei einer unbehandelten Ausnahme ausgegeben werden. Der Standardwert ist 1000. Wenn sie auf 0 oder weniger gesetzt ist, werden alle Traceback-Informationen unterdrückt und nur der Ausnahmetyp und -wert ausgegeben.

sys.unraisablehook(unraisable, /)¶

Behandelt eine unbehandelbare Ausnahme.

Wird aufgerufen, wenn eine Ausnahme aufgetreten ist, aber Python keine Möglichkeit hat, sie zu behandeln. Zum Beispiel, wenn ein Destruktor eine Ausnahme auslöst oder während der Garbage Collection (gc.collect()).

Das Argument unraisable hat die folgenden Attribute:

exc_type: Ausnahmetyp.
exc_value: Ausnahme-Wert, kann None sein.
exc_traceback: Ausnahme-Traceback, kann None sein.
err_msg: Fehlermeldung, kann None sein.
object: Objekt, das die Ausnahme verursacht, kann None sein.

Der Standard-Hook formatiert err_msg und object als: f'{err_msg}: {object!r}'; verwendet die Fehlermeldung "Exception ignored in", wenn err_msg None ist.

sys.unraisablehook() kann überschrieben werden, um zu steuern, wie unbehandelbare Ausnahmen behandelt werden.

Siehe auch

excepthook(), das nicht abgefangene Ausnahmen behandelt.

Warnung

Das Speichern von exc_value mithilfe eines benutzerdefinierten Hooks kann zu einem Referenzzyklus führen. Es sollte explizit gelöscht werden, um den Referenzzyklus zu unterbrechen, wenn die Ausnahme nicht mehr benötigt wird.

Das Speichern von object mithilfe eines benutzerdefinierten Hooks kann es wiederbeleben, wenn es auf ein Objekt gesetzt wird, das gerade finalisiert wird. Vermeiden Sie das Speichern von object nach Abschluss des benutzerdefinierten Hooks, um das Wiederbeleben von Objekten zu vermeiden.

Lösen Sie ein Audit-Ereignis sys.unraisablehook mit den Argumenten hook, unraisable aus, wenn eine nicht behandelbare Ausnahme auftritt. Das Objekt unraisable ist dasselbe wie das, was an den Hook übergeben wird. Wenn kein Hook gesetzt wurde, kann hook None sein.

Hinzugefügt in Version 3.8.

sys.version¶: Ein String, der die Versionsnummer des Python-Interpreters sowie zusätzliche Informationen über die Build-Nummer und den verwendeten Compiler enthält. Dieser String wird beim Starten des interaktiven Interpreters angezeigt. Extrahieren Sie keine Versionsinformationen daraus, sondern verwenden Sie stattdessen version_info und die Funktionen des platform-Moduls.

sys.api_version¶

Die C-API-Version, äquivalent zum C-Makro PYTHON_API_VERSION. Für Abwärtskompatibilität definiert.

Derzeit wird diese Konstante in neuen Python-Versionen nicht aktualisiert und ist für die Versionskontrolle nicht nützlich. Dies kann sich in Zukunft ändern.

sys.version_info¶: Ein Tupel, das die fünf Komponenten der Versionsnummer enthält: major, minor, micro, releaselevel und serial. Alle Werte außer releaselevel sind ganze Zahlen; die Release-Stufe ist 'alpha', 'beta', 'candidate' oder 'final'. Der version_info-Wert, der der Python-Version 2.0 entspricht, ist (2, 0, 0, 'final', 0). Die Komponenten können auch über ihren Namen abgerufen werden, sodass sys.version_info[0] äquivalent zu sys.version_info.major und so weiter ist.

Geändert in Version 3.1: Benannte Komponentenattribute hinzugefügt.

sys.warnoptions¶: Dies ist ein Implementierungsdetail des Warnungsrahmens; ändern Sie diesen Wert nicht. Weitere Informationen zum Warnungsrahmen finden Sie im warnings-Modul.

sys.winver¶: Die Versionsnummer, die zum Erstellen von Registrierungsschlüsseln unter Windows verwendet wird. Diese wird als String-Ressource 1000 in der Python-DLL gespeichert. Der Wert ist normalerweise die Haupt- und Nebenversion des laufenden Python-Interpreters. Er wird im sys-Modul zu Informationszwecken bereitgestellt; das Ändern dieses Wertes hat keine Auswirkung auf die von Python verwendeten Registrierungsschlüssel.

Verfügbarkeit: Windows.

sys.monitoring: Namespace, der Funktionen und Konstanten zum Registrieren von Rückrufen und Steuern von Überwachungsereignissen enthält. Weitere Details finden Sie unter sys.monitoring.

sys._xoptions¶

Ein Dictionary der verschiedenen implementierungsspezifischen Flags, die über die Befehlszeilenoption -X übergeben werden. Optionsnamen werden entweder ihren Werten zugeordnet, wenn sie explizit angegeben wurden, oder True. Beispiel

$ ./python -Xa=b -Xc
Python 3.2a3+ (py3k, Oct 16 2010, 20:14:50)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys._xoptions
{'a': 'b', 'c': True}

CPython-Implementierungsdetail: Dies ist eine CPython-spezifische Möglichkeit, auf über -X übergebene Optionen zuzugreifen. Andere Implementierungen exportieren sie möglicherweise auf andere Weise oder gar nicht.

Hinzugefügt in Version 3.2.

Zitate

[C99]

ISO/IEC 9899:1999. „Programming languages – C.“ Ein öffentlicher Entwurf dieses Standards ist unter https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf verfügbar.

`sys` — Systemspezifische Parameter und Funktionen¶

Vorheriges Thema

Nächstes Thema

Diese Seite

sys — Systemspezifische Parameter und Funktionen¶

`sys` — Systemspezifische Parameter und Funktionen¶