Einführung

Die Standardbibliothek von Python besteht aus einer Sammlung von Modulen. Diese Sammlung lässt sich auf viele Weisen aufteilen. Die meisten Module sind in Python geschrieben, einige aber in C. Alle lassen sich in dein Programm importieren, um es um Funktionalität zu erweitern. Manche Module stellen Schnittstellen bereit, die sehr spezifisch für Python sind, etwa das Ausgeben eines Stack-Trace. Manche stellen Schnittstellen bereit, die für bestimmte Betriebssysteme spezifisch sind, etwa den Zugriff auf bestimmte Hardware. Andere stellen Schnittstellen bereit, die für einen bestimmten Anwendungsbereich spezifisch sind, etwa die Webentwicklung. Manche Module sind in allen Fassungen und Portierungen von Python verfügbar, andere nur dann, wenn das zugrunde liegende System sie unterstützt oder erfordert, und wieder andere nur dann, wenn beim Kompilieren und Installieren von Python eine bestimmte Einrichtungsoption gewählt wurde.

Liest du dieses Handbuch von vorn und springst zum nächsten Kapitel, sobald es dir langweilig wird, bekommst du einen brauchbaren Überblick über die verfügbaren Module und Anwendungsbereiche, die die Python-Bibliothek unterstützt. Du musst es natürlich nicht wie einen Roman lesen — du kannst auch das Inhaltsverzeichnis (vor dem Handbuch) durchsehen oder im Index (hinten) nach einer bestimmten Funktion, einem Modul oder einem Begriff suchen. Und wenn du Freude daran hast, über zufällige Themen zu lernen, schlägst du schließlich eine zufällige Seite auf und liest einen Abschnitt oder zwei. In welcher Reihenfolge du die Abschnitte dieses Handbuchs auch liest, es hilft, zuerst Integrierte Funktionen zu lesen, denn der Rest dieses Abschnitts setzt Vertrautheit mit diesem Material voraus.

Siehe auch

Die integrierten Funktionen und Klassen (die sich ohne eine import-Anweisung verwenden lassen) werden in Referenz der integrierten Python-Objekte beschrieben.

Hinweise zur Verfügbarkeit

  • Ein Hinweis „Verfügbarkeit: Unix“ bedeutet, dass diese Funktion üblicherweise auf Unix-Systemen zu finden ist. Er behauptet nichts darüber, ob sie auf einem bestimmten Betriebssystem vorhanden ist.

  • Sofern nicht eigens angemerkt, werden alle Funktionen, für die „Verfügbarkeit: Unix“ angegeben ist, unter macOS, iOS und Android unterstützt, die alle auf einem Unix-Kern aufbauen.

  • Enthält ein Verfügbarkeitshinweis sowohl eine Mindestversion des Kernels als auch eine Mindestversion der libc, müssen beide Bedingungen erfüllt sein. Eine Eigenschaft mit dem Hinweis Verfügbarkeit: Linux >= 3.17 mit glibc >= 2.27 erfordert zum Beispiel 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) stellen eine Teilmenge der POSIX-APIs bereit. WebAssembly-Laufzeitumgebungen und Browser laufen in einer Sandbox und haben nur begrenzten Zugriff auf den Wirt und auf äußere Ressourcen. Jedes Modul der Python-Standardbibliothek, 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 unixartigen Systemen. Datei-E/A, Dateisystem und Funktionen rund um Unix-Rechte sind ebenfalls eingeschränkt. Emscripten erlaubt keine blockierende E/A. Andere blockierende Vorgänge wie sleep() blockieren die Ereignisschleife des Browsers.

Die Eigenschaften und das Verhalten von Python auf WebAssembly-Plattformen hängen von der Version des Emscripten-SDK oder WASI-SDK ab, von den WASM-Laufzeitumgebungen (Browser, NodeJS, wasmtime) und von den Flags, mit denen Python gebaut wurde. WebAssembly, Emscripten und WASI sind Standards in Entwicklung. Manche Eigenschaften wie das Netzwerk werden möglicherweise in Zukunft unterstützt.

Für Python im Browser sollten Nutzer Pyodide oder PyScript in Erwägung ziehen. PyScript baut auf Pyodide auf, das selbst auf CPython und Emscripten aufbaut. Pyodide bietet Zugriff auf die JavaScript- und DOM-APIs der Browser sowie begrenzte Netzwerkfähigkeiten über die JavaScript-APIs XMLHttpRequest und Fetch.

  • APIs rund um Prozesse sind nicht verfügbar oder scheitern immer mit einem Fehler. Dazu gehören APIs, die neue Prozesse starten (fork(), execve()), auf Prozesse warten (waitpid()), Signale senden (kill()) oder sonst mit Prozessen umgehen. subprocess lässt sich importieren, funktioniert aber nicht.

  • Das Modul socket ist verfügbar, aber eingeschränkt und verhält sich anders als auf anderen Plattformen. Unter Emscripten sind Sockets immer nicht blockierend und erfordern zusätzlichen JavaScript-Code und Hilfsmittel auf dem Server, um TCP über WebSockets weiterzuleiten. Weitere Informationen stehen unter Emscripten Networking. WASI Snapshot Preview 1 erlaubt Sockets nur aus einem vorhandenen Dateideskriptor.

  • Einige Funktionen sind Platzhalter, die entweder nichts tun oder stets festgelegte Werte zurückgeben.

  • Funktionen rund um Dateideskriptoren, Dateirechte, Dateieigentum und Links sind eingeschränkt und unterstützen manche Vorgänge nicht. WASI erlaubt zum Beispiel keine symbolischen Links mit absoluten Dateinamen.

Mobile Plattformen

Android und iOS sind in den meisten Belangen POSIX-Betriebssysteme. Datei-E/A, der Umgang mit Sockets und Threading verhalten sich alle so, wie sie es auf jedem POSIX-Betriebssystem täten. Es gibt allerdings mehrere wesentliche Unterschiede:

  • Mobile Plattformen können Python nur im „eingebetteten“ Modus verwenden. Es gibt keine Python-REPL und keine Möglichkeit, eigene ausführbare Programme wie python oder pip zu verwenden. Um Python-Code zu deiner mobilen App hinzuzufügen, musst du die Python-Einbettungs-API verwenden. Weitere Einzelheiten stehen unter Python unter Android verwenden und Python unter iOS verwenden.

  • Subprozesse:

    • Unter Android lassen sich Subprozesse erzeugen, das wird aber offiziell nicht unterstützt. Insbesondere unterstützt Android keinen Teil der System-V-IPC-API, weshalb multiprocessing nicht verfügbar ist.

    • Eine iOS-App kann keine Form von Subprozessen, Multiprocessing oder Interprozesskommunikation verwenden. Versucht eine iOS-App, einen Subprozess zu erzeugen, bleibt der Prozess, der den Subprozess erzeugt, entweder hängen oder stürzt ab. Eine iOS-App sieht keine anderen laufenden Anwendungen und kann auch nicht mit anderen laufenden Anwendungen kommunizieren, außer über die eigens dafür vorhandenen iOS-APIs.

  • Mobile Apps haben nur begrenzten Zugriff darauf, Systemressourcen (etwa die Systemuhr) zu ändern. Diese Ressourcen sind oft lesbar, Versuche, sie zu ändern, scheitern aber üblicherweise.

  • Ein- und Ausgabe auf der Konsole:

    • Unter Android sind die systemeigenen stdout und stderr mit nichts verbunden, deshalb richtet Python eigene Datenströme ein, die Meldungen in das Systemprotokoll umlenken. Sie sind unter den Tags python.stdout beziehungsweise python.stderr zu sehen.

    • iOS-Apps haben nur einen begrenzten Begriff von Konsolenausgabe. stdout und stderr gibt es, und was nach stdout und stderr geschrieben wird, ist beim Ausführen in Xcode in den Protokollen sichtbar, dieser Inhalt wird aber nicht im Systemprotokoll aufgezeichnet. Stellt ein Nutzer, der deine App installiert hat, seine App-Protokolle als Diagnosehilfe bereit, enthalten sie nichts von dem, was nach stdout oder stderr geschrieben wurde.

    • Mobile Apps haben überhaupt kein brauchbares stdin. Apps können zwar eine Bildschirmtastatur anzeigen, das ist aber eine Eigenschaft der Software und nichts, was an stdin hängt.

      Deshalb sind Python-Module, die mit der Konsole umgehen (etwa curses und readline), auf mobilen Plattformen nicht verfügbar.