Introduction

La « Bibliothèque Python » contient divers composants dans différentes catégories.

Elle contient des types de données qui seraient normalement considérés comme « fondamentaux » au langage, tel que les nombres et les listes. Pour ces types, le cœur du langage en définit les écritures littérales et impose quelques contraintes sémantiques, sans les définir exhaustivement. (Cependant le cœur du langage impose quelques propriétés comme l'orthographe des attributs ou les caractéristiques des opérateurs.)

La bibliothèque contient aussi des fonctions et des exceptions natives, pouvant être utilisées par tout code Python sans import. Certaines sont définies par le noyau de Python, bien qu'elles ne soient pas toutes essentielles.

La grande majorité de la bibliothèque consiste cependant en une collection de modules. Cette collection peut être parcourue de différentes manières. Certains modules sont rédigés en C et inclus dans l'interpréteur Python, d'autres sont écrits en Python et leur source est importée. Certains modules fournissent des interfaces extrêmement spécifiques à Python, tel que l'affichage d'une pile d'appels, d'autres fournissent des interfaces spécifiques à un système d'exploitation, comme l'accès à du matériel spécifique. D'autres fournissent des interfaces spécifiques à un domaine d'application, comme le World Wide Web. Certains modules sont disponibles dans toutes les versions et implémentations de Python, d'autres ne sont disponibles que si le système sous-jacent les gère ou en a besoin. Enfin, d'autres ne sont disponibles que si Python à été compilé avec une certaine option.

Cette documentation organise les modules « de l'intérieur vers l'extérieur », documentant en premier les fonctions natives, les types de données et exceptions, puis les modules, groupés par chapitre, par thématiques.

Ça signifie que si vous commencez à lire cette documentation du début, et sautez au chapitre suivant lorsqu'elle vous ennuie, vous aurez un aperçu global des modules et domaines couverts par cette bibliothèque. Bien sûr vous n'avez pas à la lire comme un roman, vous pouvez simplement survoler la table des matières (au début), ou chercher une fonction, un module, ou un mot dans l'index (à la fin). Et si vous appréciez apprendre sur des sujets au hasard, choisissez une page au hasard (avec le module random) et lisez un chapitre ou deux. Peu importe l'ordre que vous adopterez, commencez par le chapitre Fonctions natives, car les autres chapitres présument que vous en avez une bonne connaissance.

Que le spectacle commence !

Notes sur la disponibilité

• Une note « Disponibilité : Unix » signifie que cette fonction est communément implémentée dans les systèmes Unix. Une telle note ne prétend pas l'existence de la fonction sur un système d'exploitation particulier.

• If not separately noted, all functions that claim "Availability: Unix" are supported on macOS, iOS and Android, all of which build on a Unix core.

• Si une note de disponibilité contient à la fois une version minimale du noyau et une version minimale de la libc, les deux conditions doivent être remplies. Par exemple, une fonctionnalité avec la note Disponibilité : Linux >= 3.17 avec glibc >= 2.27 nécessite à la fois Linux 3.17 ou plus récent et glibc 2.27 ou plus récent.

Plateformes WebAssembly

Les plates-formes WebAssembly wasm32-emscripten (Emscripten) et wasm32-wasi (WASI) fournissent un sous-ensemble des API POSIX. Les environnements d'exécution WebAssembly et les navigateurs sont dans des bacs à sable et ont un accès limité à l'hôte et aux ressources externes. Tout module de bibliothèque standard Python qui utilise des processus, des threads, le réseau, des signaux ou d'autres formes de communication inter-processus (IPC) n'est pas disponible ou peut ne pas fonctionner comme sur d'autres systèmes de type Unix. Les entrées-sorties de fichiers, le système de fichiers et les fonctions liées aux autorisations Unix sont également restreintes. Emscripten ne permet pas d'effectuer des entrées-sorties bloquantes. D'autres opérations bloquantes comme sleep() bloquent la boucle d'événements du navigateur.

Les propriétés et le comportement de Python sur les plates-formes WebAssembly dépendent de la version du SDK Emscripten ou WASI, des programmes exécutables WASM (navigateur, NodeJS, wasmtime) et de la configuration de compilation de Python. WebAssembly, Emscripten et WASI sont des normes en évolution ; certaines fonctionnalités telles que la gestion du réseau pourraient être prises en charge à l'avenir.

Pour exécuter du Python dans le navigateur, les utilisateurs doivent envisager Pyodide ou PyScript. PyScript est construit sur Pyodide, qui est lui-même construit sur CPython et Emscripten. Pyodide donne accès aux API JavaScript et DOM des navigateurs ainsi qu'à des capacités réseau limitées avec les API XMLHttpRequest et Fetch de JavaScript.

• Les API liées aux processus ne sont pas disponibles ou échouent toujours avec une erreur. Cela inclut les API qui génèrent de nouveaux processus (fork(), execve()), attendent des processus (waitpid()), envoient des signaux (kill()), ou interagissent d'une autre manière avec les processus. Le module subprocess peut être importé mais ne fonctionne pas.

• Le module socket est disponible, mais est limité et n'a pas le même comportement que sur les autres plates-formes. Sur Emscripten, les connecteurs réseau sont toujours non bloquants et nécessitent du code JavaScript et du code supplémentaire sur le serveur pour faire mandataire TCP via WebSockets ; voir Emscripten Networking pour plus d'informations. La pré-version 1 de WASI n'autorise que les connecteurs réseau utilisant un descripteur de fichier déjà existant.

• Certaines fonctions sont des émulations embryonnaires qui ne font rien et renvoient toujours des valeurs codées en dur.

• Les fonctions liées aux descripteurs de fichiers, aux autorisations de fichiers, aux propriétaires des fichiers et aux liens sont limitées et ne prennent pas en charge certaines opérations. Par exemple, WASI n'autorise pas les liens symboliques avec des noms de fichiers absolus.

Mobile platforms

Android and iOS are, in most respects, POSIX operating systems. File I/O, socket handling, and threading all behave as they would on any POSIX operating system. However, there are several major differences:

• Mobile platforms can only use Python in "embedded" mode. There is no Python REPL, and no ability to use separate executables such as python or pip. To add Python code to your mobile app, you must use the Python embedding API. For more details, see Using Python on Android and Using Python on iOS.

• Subprocesses:

  • On Android, creating subprocesses is possible but officially unsupported. In particular, Android does not support any part of the System V IPC API, so multiprocessing is not available.

  • An iOS app cannot use any form of subprocessing, multiprocessing, or inter-process communication. If an iOS app attempts to create a subprocess, the process creating the subprocess will either lock up, or crash. An iOS app has no visibility of other applications that are running, nor any ability to communicate with other running applications, outside of the iOS-specific APIs that exist for this purpose.

• Mobile apps have limited access to modify system resources (such as the system clock). These resources will often be readable, but attempts to modify those resources will usually fail.

• Console input and output:

  • On Android, the native stdout and stderr are not connected to anything, so Python installs its own streams which redirect messages to the system log. These can be seen under the tags python.stdout and python.stderr respectively.

  • iOS apps have a limited concept of console output. stdout and stderr exist, and content written to stdout and stderr will be visible in logs when running in Xcode, but this content won't be recorded in the system log. If a user who has installed your app provides their app logs as a diagnostic aid, they will not include any detail written to stdout or stderr.

  • Mobile apps have no usable stdin at all. While apps can display an on-screen keyboard, this is a software feature, not something that is attached to stdin.

    As a result, Python modules that involve console manipulation (such as curses and readline) are not available on mobile platforms.