Pengenalan
**********

"Pustaka Python" berisi beberapa jenis komponen.

Ini berisi tipe data yang biasanya dianggap bagian "inti" dari bahasa,
seperti angka dan daftar *list*. Untuk tipe ini, inti bahasa Python
mendefinisikan bentuk literal dan menempatkan beberapa batasan pada
semantiknya, tetapi tidak sepenuhnya mendefinisikan semantik. (Di sisi
lain, inti bahasa mendefinisikan properti sintaksis seperti ejaan dan
prioritas operator.)

Pustaka juga berisi fungsi dan pengecualian bawaan --- objek yang
dapat digunakan oleh semua kode Python tanpa memerlukan pernyataan
"import". Beberapa di antaranya didefinisikan oleh bahasa inti, tetapi
banyak yang tidak esensial untuk semantik inti dan hanya dijelaskan di
sini.

Namun, sebagian besar pustaka terdiri dari kumpulan modul. Ada banyak
cara untuk membedah koleksi ini. Beberapa modul ditulis dalam C dan
dibangun ke dalam interpreter Python; yang lain ditulis dengan Python
dan diimpor dalam bentuk sumber. Beberapa modul menyediakan antarmuka
yang sangat spesifik untuk Python, seperti mencetak tumpukan jejak
*stack trace*; beberapa menyediakan antarmuka yang khusus untuk sistem
operasi tertentu, seperti akses ke perangkat keras tertentu; yang lain
menyediakan antarmuka yang khusus untuk domain aplikasi tertentu,
seperti *World Wide Web*. Beberapa modul tersedia di semua versi dan
port dari Python; yang lain hanya tersedia ketika sistem yang
mendasarinya mendukung atau membutuhkannya; yang lain hanya tersedia
ketika opsi konfigurasi tertentu dipilih pada saat Python dikompilasi
dan diinstal.

Manual ini disusun "dari dalam ke luar:" pertama-tama menggambarkan
fungsi bawaan, tipe data dan pengecualian, dan akhirnya modul,
dikelompokkan dalam bab-bab modul terkait.

Ini berarti bahwa jika Anda mulai membaca manual ini dari awal, dan
melompat ke bab berikutnya ketika Anda bosan, Anda akan mendapatkan
gambaran umum yang masuk akal dari modul yang tersedia dan area
aplikasi yang didukung oleh pustaka Python. Tentu saja, Anda tidak
*harus* membacanya seperti novel --- Anda juga dapat menelusuri daftar
isi (di depan manual), atau mencari fungsi, modul, atau istilah
tertentu dalam indeks (dalam bagian belakang). Dan akhirnya, jika Anda
menikmati belajar tentang subjek acak, Anda memilih nomor halaman acak
(lihat modul "random") dan baca satu atau dua bagian. Terlepas dari
urutan di mana Anda membaca bagian-bagian dari manual ini, ada baiknya
untuk memulai dengan bab Fungsi Bawaan, karena sisa manual
mengasumsikan terbiasa dengan materi ini.

Biarkan pertunjukan dimulai!


Catatan tentang ketersediaan
============================

* Catatan "Ketersediaan: Unix" berarti bahwa fungsi ini biasanya
  ditemukan pada sistem Unix. Itu tidak membuat klaim tentang
  keberadaannya pada sistem operasi tertentu.

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