概述
****

Python 标准库由一系列模块组成。 对这套集合有多种划分方式。 大多数模块
是用 Python 编写的，但也有一些是用 C 编写的。 它们都可以导入到你的程序
中以增加功能。 某些模块提供高度针对 Python 的接口，例如打印堆栈回溯；
某些模块提供针对特定操作系统的接口，例如访问特定硬件；还有一些模块提供
针对特定应用领域的接口，例如 Web 开发。 某些模块在 Python 的所有版本和
移植版中均可用；其他模块仅在下层系统支持或需要它们时才可用；还有一些模
块仅在编译和安装 Python 时选择了特定配置选项时才可用。

如果你从头开始阅读本手册，并在感到乏味时跳到下一章，你将对 Python 库所
支持的可用模块和应用领域获得合理的全面了解。 当然，你并不 *一定* 要像
读小说一样通读它 --- 你也可以浏览目录（在手册前面），或在索引（在手册
后面）中查找特定的函数、模块或术语。 最后，如果你喜欢了解各种随机主题
，你可以挑选一个随机页面阅读一两个小节。 无论你以何种顺序阅读本手册的
各个章节，先阅读 内置函数 都会很有帮助，因为本节的其余部分假定你已熟悉
这些内容。

参见: 内置函数和类（无需使用 "import" 语句即可使用）在 Python 内置对象参考
    中进行了描述。


可用性注释
==========

* 如果出现“适用：Unix”注释，意味着相应函数通常存在于 Unix 系统中。 但
  这并不保证其存在于某个特定的操作系统中。

* 如果没有单独注明，所有声称"可用性：Unix"的函数都支持 macOS、iOS 和
  Android ，所有这些构建都基于 Unix 内核。

* 如果一条可用性注释同时包含最低 Kernel 版本和最低 libc 版本，则两个条
  件都必须满足。 例如当某个特性带有注释 *可用性: Linux >= 3.17 且
  glibc >= 2.27* 则表示同时要求 Linux 3.17 以上版本和 glibc 2.27 以上
  版本。


WebAssembly 平台
----------------

WebAssembly 平台 "wasm32-emscripten" (Emscripten) 和 "wasm32-wasi"
(WASI) 分别提供了 POSIX API 的一个子集。 WebAssembly 运行时和浏览器都
处于沙盒模式中并具有对主机和外部资源的受限访问权。 任何使用了进程、线
程、网络、信号或其他形式的进程间通信 (IPC) 的 Python 标准库模块都或者
不可用，或者其作用方式与在其他类 Unix 系统上不同。 文件 I/O, 文件系统
和 Unix 权限相关的函数也同样会受限。 Emscripten 不允许阻塞式 I/O。 其
他阻塞式操作如 "sleep()" 则会阻塞浏览器的事件循环。

Python 在 WebAssembly 平台上的特性与行为依赖于 Emscripten-SDK 或 WASI-
SDK 的版本, WASM 运行时 (浏览器, NodeJS, wasmtime) 以及 Python 编译时
旗标。 WebAssembly, Emscripten 和 WASI 都是尚在不断演化中的标准；某些
特性例如网络可能会在未来被支持。

对于在浏览器上运行的 Python，用户可以考虑 Pyodide 或 PyScript。
PyScript 是在 Pyodide 之上构建的，后者本身则是在 CPython 和 Emscripten
之上构建的。 Pyodide 提供了对浏览器的 JavaScript 和 DOM API 的访问并通
过 JavaScript 的 "XMLHttpRequest" 和 "Fetch" API 提供了受限的网络功能
。

* 进程相关的 API 或者不可用或者将始终报错失败。 这包括生成新进程
  ("fork()", "execve()"), 等待进程 ("waitpid()"), 发送信号 ("kill()")
  或者以其他方式与进程交互的 API。 "subprocess" 可以被导入但将没有任何
  作用。

* "socket" 模块可以使用，但将会受限而使其行为与在其他平台上不一致。 在
  Emscripten 上，套接字将始终为非阻塞式的并且要求额外的 JavaScript 代
  码和服务器上的辅助工具来代理通过 WebSockets 的 TCP；请参阅
  Emscripten Networking 了解详情。 WASI snapshot preview 1 只允许来自
  现有文件描述符的套接字。

* 某些函数是不执行任何操作的空壳或是始终返回硬编码的值。

* 有关文件描述符、文件访问权、文件所有权和链接的函数均受到限制并且不支
  持某些操作。 例如，WASI 不允许具有绝对文件名的符号链接。


移动平台
--------

Android 和 iOS 在大多数方面都是 POSIX 操作系统。文件 I/O、套接字处理和
线程的行为都与在任何 POSIX 操作系统上的行为相同。但是，有几个主要区别
：

* 移动平台只能在"嵌入"模式下使用 Python。没有 Python REPL，也不能使用
  单独的可执行文件，如 **python** 或 **pip** 。要在移动应用程序中添加
  Python 代码，必须使用 Python 嵌入式 API  。更多详情，请参阅 在
  Android上使用 Python 和 在 iOS 上使用 Python 。

* 子进程：

  * 在 Android 上，创建子进程是可能的，但属于官方不支持的。尤其是，
    Android 不支持 System V IPC API 的任何部分，因此 "multiprocessing"
    不可用。

  * iOS 应用程序不能使用任何形式的子进程、多进程或进程间通信。如果 iOS
    应用程序尝试创建子进程，创建子进程的进程要么会卡死，要么会崩溃。
    iOS 应用程序无法看到正在运行的其他应用 ，也无法与运行中的其他应用
    通信，除非使用为此目的而存在的 iOS 特定 API 。

* 移动应用程序修改系统资源（如系统时钟）的权限有限。这些资源通常*可读*
  ，但试图修改这些资源通常会失败。

* 控制台输入与输出：

  * 在 Android 系统上，原生的 "stdout" 和 "stderr" 没有连接到任何设备
    ，因此 Python 安装了自己的流，将信息重定向到系统日志。这些信息可分
    别在 "python.stdout" 和 "python.stderr" 标签下看到。

  * iOS 应用程序对控制台输出的概念有限。 "stdout" 和 "stderr" *存在*，
    在 Xcode 中运行时，写入 "stdout" 和 "stderr" 的内容在日志中可见，
    但这些内容 *不会* 记录在系统日志中。 如果安装了您的应用程序的用户
    提供其应用程序日志作为诊断辅助工具，这些日志将不包括写入 "stdout"
    或 "stderr" 的任何细节。

  * 移动应用程序根本没有可用的 "stdin" 。虽然应用程序可以显示屏幕键盘
    ，但这是软件特性 ，而不是连接在 "stdin" 上的。

    因此，涉及控制台操作的 Python 模块（如 "curses" 和 "readline" ）无
    法在移动平台上使用。
