소개
****

"파이썬 라이브러리"에는 여러 가지 구성 요소가 포함되어 있습니다.

여기에는 일반적으로 숫자 및 리스트와 같이 언어의 "핵심" 부분으로 간주
하는 데이터형이 포함됩니다. 이러한 형의 경우, 파이썬 언어 핵심은 리터
럴의 형식을 정의하고 그 의미에 몇 가지 제약을 가하지만, 의미를 완전히
정의하지는 않습니다. (반면에, 언어 핵심은 연산자의 철자법과 우선순위와
같은 문법적 속성을 정의합니다.)

라이브러리는 또한 내장 함수와 예외를 포함합니다 --- "import" 문을 쓰지
않고도 모든 파이썬 코드에서 사용할 수 있는 객체들입니다. 이들 중 일부
는 언어 핵심에 의해 정의되지만, 핵심 의미에 필수적인 것은 아니며 여기
에서 설명합니다.

그러나 라이브러리 대부분은 모듈 컬렉션으로 구성됩니다. 이 컬렉션을 나
누는 데는 여러 가지 방법이 있습니다. 일부 모듈은 C로 작성되고 파이썬
인터프리터에 내장되어 있습니다; 다른 것은 파이썬으로 작성되고 소스 형
식으로 임포트 됩니다. 일부 모듈은 스택 추적 인쇄와 같이 파이썬에 매우
특정한 인터페이스를 제공합니다; 일부는 특정 하드웨어에 대한 액세스와
같이 운영 체제에 특정한 인터페이스를 제공합니다; 다른 것은 월드 와이드
웹과 같은 응용 프로그램 영역에 특정한 인터페이스를 제공합니다. 일부 모
듈은 파이썬의 모든 버전과 이식에서 사용할 수 있습니다; 다른 것은 하위
시스템이 지원하거나 요구할 때만 사용할 수 있습니다; 그러나 다른 것들은
파이썬이 컴파일되고 설치될 때 특정 설정 옵션이 선택되었을 때만 사용할
수 있습니다.

이 설명서는 "안쪽에서부터 밖으로" 구성되어 있습니다. 먼저 내장 함수,
데이터형 및 예외, 마지막으로 관련 모듈의 장으로 그룹화된 모듈들을 설명
합니다.

즉, 처음부터 이 설명서를 읽고, 지루할 때 다음 장으로 건너뛰면, 파이썬
라이브러리가 지원하는 사용 가능한 모듈과 응용 프로그램 영역에 대한 적
당한 개요를 얻게 됩니다. 물론 소설처럼 읽을 필요는 없습니다. (설명서
앞에 있는) 목차를 검색하거나, (뒤에 있는) 색인에서 특정 함수, 모듈 또
는 용어를 찾을 수도 있습니다. 그리고 마지막으로, 무작위 주제에 대해 배
우는 것을 즐긴다면, 임의의 페이지 번호 (모듈 "random" 참조)를 선택하고
한두 섹션을 읽으면 됩니다. 이 설명서의 섹션을 읽는 순서와 관계없이, 내
장 함수 장에서 시작하는 것이 도움이 되는데, 설명서의 나머지 부분은 이
내용에 익숙하다고 가정하기 때문입니다.

쇼를 시작합시다!


가용성에 대한 참고 사항
=======================

* "가용성: 유닉스" 참고 사항은 이 기능이 유닉스 시스템에서 일반적으로
  발견된다는 것을 뜻합니다. 특정 운영 체제에 이 기능이 존재하는지에 관
  한 어떠한 주장도 하지 않습니다.

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

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

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.


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.
