簡介
****

「Python 函式庫」包含了許多不同的部分。

函式庫中包括被視為程式語言「核心」部分的資料型態，像是數字 (number) 或
是串列 (list)。對於這些型別，Python 核心對這些字面值 (literal) 的形式
做定義，並對它們的語意制定了一些限制，但在此同時卻不把文字對應的語意完
全定義。（另一方面，Python 在語法面上有確實的定義，例如拼字或是運算元
次序）

Python 函式庫也囊括了內建函式與例外處理——這些物件都可以不用透過
"import" 陳述式來引入 Python 程式中就能使用。函式庫中有部份是被 Python
核心所定義的，但在這裡僅解釋最核心的語意部分。

整個函式庫中包含了許多模組，有許多方法可以從函式庫中取用這些模組。有些
模組是以 C 語言撰寫並建置於 Python 編譯器之中，其他的是由 Python 撰寫
並以源碼的方式 (source form) 引入。有些模組提供的功能是專屬於 Python
的，像是把 stack trace 印出來；有些則是針對特定作業系統，去試著存取特
定硬體；還有些提供對特定應用的功能與操作介面，像是 World Wide Web。模
組的使用情況會因機器與 Python 的版本而不同，部分模組是開放所有版本以及
Port 的 Python 來使用的，但有些會因系統支援或需求在某些版本或系統下無
法使用，甚至有些僅限在特定的設定環境下才能使用。

這個手冊會「深入淺出」地介紹 Python 函式庫。它會先介紹一些內建函式、資
料型態、和一些例外處理，再來一章章的主題式介紹相關模組。

這代表如果你從這個手冊的最開始讀起，並在感到無聊時跳到下一個章節，你仍
然可以得到一個對 Python 函式庫所支援的模組與其合理應用的概觀。當然，你
*沒有必要*像是在讀一本小說一樣讀這本手冊——你可以快速瀏覽目錄（在手冊的
最前頭）、或是你可以利用最後面的索引來查詢特定的函式或模組。最後，如果
你享受閱讀一些隨機的主題，你可以選擇一個隨機的數字並開始閱讀（見
"random" 模組) 。不管你想要以什麼順序來閱讀這個手冊，內建函式會是一個
很好的入門，因為手冊中其他章節都預設你已經對這個章節有一定的熟悉程度。

讓我們開始吧！


可用性之標註
============

* 如果出現「適用：Unix」標註，則代表該函式普遍存在於 Unix 系統中，但這
  並不保證其存在於某特定作業系統。

* 如果沒有分別標註的話，有標明「適用：Unix」標註的所有函式也都於 macOS
  、iOS 和 Android 上支援，因其建於 Unix 核心之上。

* If an availability note contains both a minimum Kernel version and a
  minimum libc version, then both conditions must hold. For example a
  feature with note *Availability: Linux >= 3.17 with glibc >= 2.27*
  requires both Linux 3.17 or newer and glibc 2.27 or newer.


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

The WebAssembly platforms "wasm32-emscripten" (Emscripten) and
"wasm32-wasi" (WASI) provide a subset of POSIX APIs. WebAssembly
runtimes and browsers are sandboxed and have limited access to the
host and external resources. Any Python standard library module that
uses processes, threading, networking, signals, or other forms of
inter-process communication (IPC), is either not available or may not
work as on other Unix-like systems. File I/O, file system, and Unix
permission-related functions are restricted, too. Emscripten does not
permit blocking I/O. Other blocking operations like "sleep()" block
the browser event loop.

The properties and behavior of Python on WebAssembly platforms depend
on the Emscripten-SDK or WASI-SDK version, WASM runtimes (browser,
NodeJS, wasmtime), and Python build time flags. WebAssembly,
Emscripten, and WASI are evolving standards; some features like
networking may be supported in the future.

For Python in the browser, users should consider Pyodide or PyScript.
PyScript is built on top of Pyodide, which itself is built on top of
CPython and Emscripten. Pyodide provides access to browsers'
JavaScript and DOM APIs as well as limited networking capabilities
with JavaScript's "XMLHttpRequest" and "Fetch" APIs.

* Process-related APIs are not available or always fail with an error.
  That includes APIs that spawn new processes ("fork()", "execve()"),
  wait for processes ("waitpid()"), send signals ("kill()"), or
  otherwise interact with processes. The "subprocess" is importable
  but does not work.

* The "socket" module is available, but is limited and behaves
  differently from other platforms. On Emscripten, sockets are always
  non-blocking and require additional JavaScript code and helpers on
  the server to proxy TCP through WebSockets; see Emscripten
  Networking for more information. WASI snapshot preview 1 only
  permits sockets from an existing file descriptor.

* Some functions are stubs that either don't do anything and always
  return hardcoded values.

* Functions related to file descriptors, file permissions, file
  ownership, and links are limited and don't support some operations.
  For example, WASI does not permit symlinks with absolute file names.


行動平台
--------

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.
