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.
