Einleitung

Die „Python-Bibliothek“ enthält verschiedene Arten von Komponenten.

Sie enthält Datentypen, die normalerweise als Teil des „Kerns“ einer Sprache betrachtet würden, wie z. B. Zahlen und Listen. Für diese Typen definiert der Kern der Python-Sprache die Form von Literalen und setzt einige Einschränkungen für ihre Semantik, definiert die Semantik jedoch nicht vollständig. (Andererseits definiert der Kern der Sprache syntaktische Eigenschaften wie die Schreibweise und Priorität von Operatoren.)

Die Bibliothek enthält auch eingebaute Funktionen und Ausnahmen – Objekte, die von jedem Python-Code ohne die Notwendigkeit einer `import`-Anweisung verwendet werden können. Einige davon sind durch den Kern der Sprache definiert, aber viele sind für die Kernsemantik nicht unerlässlich und werden hier nur beschrieben.

Der Großteil der Bibliothek besteht jedoch aus einer Sammlung von Modulen. Es gibt viele Möglichkeiten, diese Sammlung zu zerlegen. Einige Module sind in C geschrieben und im Python-Interpreter integriert; andere sind in Python geschrieben und werden in Quellform importiert. Einige Module stellen Schnittstellen bereit, die stark spezifisch für Python sind, wie z. B. das Drucken eines Stack-Trace; einige stellen Schnittstellen bereit, die spezifisch für bestimmte Betriebssysteme sind, wie z. B. der Zugriff auf bestimmte Hardware; andere stellen Schnittstellen bereit, die spezifisch für einen bestimmten Anwendungsbereich sind, wie z. B. das World Wide Web. Einige Module sind in allen Versionen und Ports von Python verfügbar; andere sind nur verfügbar, wenn das zugrunde liegende System sie unterstützt oder erfordert; wieder andere sind nur verfügbar, wenn zur Zeit der Kompilierung und Installation von Python eine bestimmte Konfigurationsoption gewählt wurde.

Dieses Handbuch ist „von innen nach außen“ aufgebaut: Zuerst werden die eingebauten Funktionen, Datentypen und Ausnahmen beschrieben und schließlich die Module, gruppiert in Kapiteln verwandter Module.

Das bedeutet, dass Sie, wenn Sie dieses Handbuch von Anfang an lesen und zum nächsten Kapitel springen, wenn Sie sich langweilen, einen angemessenen Überblick über die verfügbaren Module und Anwendungsbereiche erhalten, die von der Python-Bibliothek unterstützt werden. Natürlich müssen Sie es nicht wie einen Roman lesen – Sie können auch das Inhaltsverzeichnis (vorne im Handbuch) durchsuchen oder im Index (hinten) nach einer bestimmten Funktion, einem Modul oder einem Begriff suchen. Und schließlich, wenn Sie gerne über zufällige Themen lernen, können Sie eine zufällige Seitenzahl wählen (siehe Modul `random`) und ein oder zwei Abschnitte lesen. Unabhängig von der Reihenfolge, in der Sie die Abschnitte dieses Handbuchs lesen, ist es hilfreich, mit dem Kapitel „Eingebaute Funktionen“ zu beginnen, da der Rest des Handbuchs Kenntnisse dieses Materials voraussetzt.

Möge die Show beginnen!

Hinweise zur Verfügbarkeit

• Ein Hinweis „Verfügbarkeit: Unix“ bedeutet, dass diese Funktion üblicherweise auf Unix-Systemen zu finden ist. Sie macht keine Aussagen über ihre Existenz auf einem bestimmten Betriebssystem.

• Sofern nicht separat vermerkt, werden alle Funktionen, die „Verfügbarkeit: Unix“ beanspruchen, auf macOS, iOS und Android unterstützt, die alle auf einem Unix-Kern basieren.

• Wenn ein Verfügbarkeitshinweis sowohl eine minimale Kernel-Version als auch eine minimale libc-Version enthält, müssen beide Bedingungen erfüllt sein. Zum Beispiel erfordert ein Feature mit dem Hinweis *Verfügbarkeit: Linux >= 3.17 mit glibc >= 2.27* sowohl Linux 3.17 oder neuer als auch glibc 2.27 oder neuer.

WebAssembly-Plattformen

Die WebAssembly-Plattformen `wasm32-emscripten` (Emscripten) und `wasm32-wasi` (WASI) bieten eine Teilmenge von POSIX-APIs. WebAssembly-Laufzeitumgebungen und Browser sind sandboxed und haben begrenzten Zugriff auf die Host- und externe Ressourcen. Jedes Python-Standardbibliotheksmodul, das Prozesse, Threading, Netzwerk, Signale oder andere Formen der Interprozesskommunikation (IPC) verwendet, ist entweder nicht verfügbar oder funktioniert möglicherweise nicht wie auf anderen Unix-ähnlichen Systemen. Datei-I/O, Dateisystem und Funktionen im Zusammenhang mit Unix-Berechtigungen sind ebenfalls eingeschränkt. Emscripten erlaubt kein blockierendes I/O. Andere blockierende Operationen wie `time.sleep()` blockieren die Browser-Ereignisschleife.

Die Eigenschaften und das Verhalten von Python auf WebAssembly-Plattformen hängen von der Version des Emscripten-SDK oder WASI-SDK, WASM-Laufzeitumgebungen (Browser, NodeJS, wasmtime) und Python-Build-Flags ab. WebAssembly, Emscripten und WASI sind sich entwickelnde Standards; einige Features wie Netzwerke könnten in Zukunft unterstützt werden.

Für Python im Browser sollten Benutzer Pyodide oder PyScript in Betracht ziehen. PyScript baut auf Pyodide auf, das selbst auf CPython und Emscripten aufbaut. Pyodide bietet Zugriff auf die JavaScript- und DOM-APIs des Browsers sowie begrenzte Netzwerkmöglichkeiten mit den JavaScript-APIs `XMLHttpRequest` und `Fetch`.

• Prozessbezogene APIs sind nicht verfügbar oder schlagen immer mit einem Fehler fehl. Dazu gehören APIs, die neue Prozesse starten (`os.fork()`, `os.execve()`), auf Prozesse warten (`os.waitpid()`), Signale senden (`os.kill()`) oder anderweitig mit Prozessen interagieren. Das Modul `subprocess` ist importierbar, funktioniert aber nicht.

• Das Modul `socket` ist verfügbar, ist aber eingeschränkt und verhält sich anders als auf anderen Plattformen. Auf Emscripten sind Sockets immer nicht blockierend und erfordern zusätzlichen JavaScript-Code und Helfer auf dem Server, um TCP über WebSockets zu proxyen; siehe Emscripten Networking für weitere Informationen. WASI Snapshot Preview 1 erlaubt nur Sockets von einem vorhandenen Dateideskriptor.

• Einige Funktionen sind Stubs, die entweder nichts tun und immer hartcodierte Werte zurückgeben.

• Funktionen, die sich auf Dateideskriptoren, Dateiberechtigungen, Dateieigentümerschaft und Links beziehen, sind eingeschränkt und unterstützen einige Operationen nicht. Zum Beispiel erlaubt WASI keine Symlinks mit absoluten Dateinamen.

Mobile Plattformen

Android und iOS sind in den meisten Aspekten POSIX-Betriebssysteme. Datei-I/O, Socket-Handling und Threading verhalten sich so, wie sie es auf jedem POSIX-Betriebssystem tun würden. Es gibt jedoch mehrere wichtige Unterschiede.

• Mobile Plattformen können Python nur im „eingebetteten“ Modus verwenden. Es gibt keine Python-REPL und keine Möglichkeit, separate ausführbare Dateien wie `python` oder `pip` zu verwenden. Um Ihrer mobilen App Python-Code hinzuzufügen, müssen Sie die Python-Embedding-API verwenden. Weitere Details finden Sie unter „Python unter Android verwenden“ und „Python unter iOS verwenden“.

• Subprozesse

  • Unter Android ist die Erstellung von Unterprozessen möglich, aber offiziell nicht unterstützt. Insbesondere Android unterstützt keinen Teil der System V IPC API, daher ist `multiprocessing` nicht verfügbar.

  • Eine iOS-App kann keine Form von Subprozessing, Multiprocessing oder Interprozesskommunikation verwenden. Wenn eine iOS-App versucht, einen Unterprozess zu erstellen, friert der Prozess, der den Unterprozess erstellt, ein oder stürzt ab. Eine iOS-App hat keine Sichtbarkeit anderer laufender Anwendungen und keine Möglichkeit, mit anderen laufenden Anwendungen zu kommunizieren, außerhalb der spezifischen iOS-APIs, die für diesen Zweck existieren.

• Mobile Apps haben nur begrenzten Zugriff auf die Änderung von Systemressourcen (wie z. B. die Systemuhr). Diese Ressourcen sind oft *lesbar*, aber Versuche, diese Ressourcen zu ändern, schlagen in der Regel fehl.

• Konsoleneingabe und -ausgabe

  • Unter Android sind die nativen `stdout` und `stderr` mit nichts verbunden, daher installiert Python eigene Streams, die Meldungen an das Systemprotokoll umleiten. Diese können unter den Tags `python.stdout` und `python.stderr` bzw. gefunden werden.

  • iOS-Apps haben ein begrenztes Konzept der Konsolenausgabe. `stdout` und `stderr` *existieren*, und Inhalte, die in `stdout` und `stderr` geschrieben werden, sind in Protokollen sichtbar, wenn die App in Xcode ausgeführt wird. Diese Inhalte werden jedoch *nicht* im Systemprotokoll aufgezeichnet. Wenn ein Benutzer, der Ihre App installiert hat, seine App-Protokolle als Diagnosehilfe bereitstellt, enthalten diese keine Details, die in `stdout` oder `stderr` geschrieben wurden.

  • Mobile Apps haben überhaupt keine nutzbare `stdin`. Obwohl Apps eine Bildschirmtastatur anzeigen können, ist dies eine Softwarefunktion, die nicht an `stdin` angeschlossen ist.

    Daher sind Python-Module, die Konsolenmanipulationen beinhalten (wie `curses` und `readline`), auf mobilen Plattformen nicht verfügbar.