Introduction
************

The Python standard library consists of a collection of modules. There
are many ways to dissect this collection.  Most modules are written in
Python, but some are written in C. All can be imported into your
program to add functionality.  Some modules provide interfaces that
are highly specific to Python, like printing a stack trace; some
provide interfaces that are specific to particular operating systems,
such as access to specific hardware; others provide interfaces that
are specific to a particular application domain, like web development.
Some modules are available in all versions and ports of Python; others
are only available when the underlying system supports or requires
them; yet others are available only when a particular configuration
option was chosen at the time when Python was compiled and installed.

If you start reading this manual from the start, and skip to the next
chapter when you get bored, you will get a reasonable overview of the
available modules and application areas that are supported by the
Python library.  Of course, you don't *have* to read it like a novel
--- you can also browse the table of contents (in front of the
manual), or look for a specific function, module or term in the index
(in the back).  And finally, if you enjoy learning about random
subjects, you choose a random page and read a section or two.
Regardless of the order in which you read the sections of this manual,
it helps to first read Built-in functions, as the remainder of this
section assumes familiarity with this material.

Voir aussi:

  The built-in functions and classes (which can be used without an
  "import" statement) are described in Python built-ins reference.


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.
