概述
****

"Python 库"中包含了几种不同的组件。

它包含通常被视为语言“核心”中的一部分的数据类型，例如数字和列表。对于这
些类型，Python语言核心定义了文字的形式，并对它们的语义设置了一些约束，
但没有完全定义语义。（另一方面，语言核心确实定义了语法属性，如操作符的
拼写和优先级。）

这个库也包含了内置函数和异常 --- 不需要 "import" 语句就可以在所有
Python代码中使用的对象。有一些是由语言核心定义的，但是许多对于核心语义
不是必需的，并且仅在这里描述。

不过这个库主要是由一系列的模块组成。这些模块集可以不同方式分类。有些模
块是用 C 编写并内置于 Python 解释器中；另一些模块则是用 Python 编写并
以源码形式导入。有些模块提供专用于 Python 的接口，例如打印栈追踪信息；
有些模块提供专用于特定操作系统的接口，例如操作特定的硬件；另一些模块则
提供针对特定应用领域的接口，例如万维网。有些模块在所有更新和移植版本的
Python 中可用；另一些模块仅在底层系统支持或要求时可用；还有些模块则仅
当编译和安装 Python 时选择了特定配置选项时才可用。

本手册以 "从内到外" 的顺序组织：首先描述内置函数、数据类型和异常，最后
是根据相关性进行分组的各种模块。

这意味着如果你从头开始阅读本手册，并在感到厌烦时跳到下一章，你仍能对
Python 库的可用模块和所支持的应用领域有个大致了解。当然，你并非 *必须*
如同读小说一样从头读到尾 --- 你也可以先浏览内容目录 (在手册开头)，或在
索引 (在手册末尾) 中查找某个特定函数、模块或条目。最后，如果你喜欢随意
学习某个主题，你可以选择一个随机页码 (参见 "random" 模块) 并读上一两小
节。无论你想以怎样的顺序阅读本手册，还是建议先从 内置函数 这一章开始，
因为本手册的其余内容都需要你熟悉其中的基本概念。

让我们开始吧！


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

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

* 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.

* 如果一条可用性注释同时包含最低 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 不允许具有绝对文件名的符号链接。


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 在 iOS 上使用 Python.

* 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.
