소개¶

파이썬 표준 라이브러리는 모듈의 집합으로 구성됩니다. 이 모음은 여러 방식으로 분류할 수 있습니다. 대부분의 모듈은 파이썬으로 작성되었지만, 일부는 C로 작성되었습니다. 이 모든 모듈은 기능 추가를 위해 프로그램으로 임포트할 수 있습니다. 일부 모듈은 스택 트레이스 출력과 같이 파이썬에 매우 특화된 인터페이스를 제공하고, 일부는 특정 하드웨어 접근과 같이 특정 운영 체제에 특화된 인터페이스를 제공하며, 다른 것들은 웹 개발과 같이 특정 응용 분야에 특화된 인터페이스를 제공합니다. 일부 모듈은 파이썬의 모든 버전과 포트에서 사용 가능하고, 일부는 하위 시스템이 지원하거나 요구하는 경우에만 사용 가능하며, 또 다른 것들은 파이썬이 컴파일되고 설치될 때 특정 구성 옵션이 선택된 경우에만 사용 가능합니다.

이 매뉴얼을 처음부터 읽기 시작하고 지루할 때 다음 장으로 넘어가면, 파이썬 라이브러리가 지원하는 사용 가능한 모듈과 응용 분야에 대한 적절한 개요를 얻을 수 있습니다. 물론 소설처럼 읽어야 할 필요는 없습니다. 매뉴얼 앞부분의 목차를 훑어보거나, 뒷부분의 색인에서 특정 함수, 모듈 또는 용어를 찾을 수도 있습니다. 마지막으로, 무작위 주제에 대해 배우는 것을 즐긴다면 임의의 페이지를 선택하여 한두 섹션을 읽어보십시오. 이 매뉴얼의 섹션을 읽는 순서와 관계없이, 이 섹션의 나머지 부분들이 이 내용을 숙지하고 있다고 가정하므로 내장 함수 를 먼저 읽는 것이 도움이 됩니다.

(import 문 없이 사용할 수 있는) 내장 함수와 클래스는 Python 내장 기능 레퍼런스 에 설명되어 있습니다.

가용성에 대한 참고 사항¶

“가용성: 유닉스” 참고 사항은 이 기능이 유닉스 시스템에서 일반적으로 발견된다는 것을 뜻합니다. 특정 운영 체제에 이 기능이 존재하는지에 관한 어떠한 주장도 하지 않습니다.
별도로 언급되지 않은 경우, “가용성: 유닉스”를 주장하는 모든 기능은 유닉스 코어를 기반으로 하는 맥 OS, iOS 및 안드로이드에서 지원됩니다.
가용성(availability) 노트에 최소 커널 버전과 최소 libc 버전이 모두 포함된 경우, 두 조건이 모두 충족되어야 합니다. 예를 들어, Availability: Linux >= 3.17 with glibc >= 2.27 이라는 노트를 가진 기능은 Linux 3.17 이상 및 glibc 2.27 이상을 모두 요구합니다.

웹어셈블리 플랫폼¶

WebAssembly 플랫폼인 wasm32-emscripten (Emscripten) 및 wasm32-wasi (WASI)는 POSIX API의 일부만 제공합니다. WebAssembly 런타임과 브라우저는 샌드박스 처리되어 호스트 및 외부 리소스에 대한 접근이 제한됩니다. 프로세스, 스레딩, 네트워킹, 시그널 또는 기타 형태의 프로세스 간 통신(IPC)을 사용하는 모든 파이썬 표준 라이브러리 모듈은 사용이 불가능하거나 다른 유사 Unix 시스템에서와 다르게 작동할 수 있습니다. 파일 I/O, 파일 시스템 및 Unix 권한 관련 기능도 제한됩니다. Emscripten은 차단(blocking) I/O를 허용하지 않습니다. sleep() 과 같은 기타 차단 작업은 브라우저 이벤트 루프를 차단합니다.

WebAssembly 플랫폼에서 파이썬의 속성과 동작은 Emscripten SDK 또는 WASI SDK 버전, WASM 런타임(브라우저, NodeJS, wasmtime), 그리고 파이썬 빌드 시점의 플래그에 따라 달라집니다. WebAssembly, Emscripten 및 WASI는 발전 중인 표준이며, 네트워킹과 같은 일부 기능은 향후 지원될 수 있습니다.

브라우저용 파이썬을 사용하는 경우 Pyodide 또는 PyScript 를 고려해야 합니다. PyScript는 Pyodide 위에서 구축되었으며, Pyodide 자체는 CPython 및 Emscripten 위에서 구축되었습니다. Pyodide는 브라우저의 JavaScript 및 DOM API에 액세스할 수 있게 해주며, 자바스크립트의 XMLHttpRequest 및 Fetch API를 통해 제한된 네트워킹 기능을 제공합니다.

프로세스 관련 API는 사용이 불가능하거나 항상 오류와 함께 실패합니다. 여기에는 새 프로세스를 생성하는 기능(fork(), execve()), 프로세스를 대기하는 기능(waitpid()), 시그널을 보내는 기능(kill()), 또는 기타 프로세스와 상호작용하는 기능이 포함됩니다. subprocess 는 가져올 수 있지만 작동하지 않습니다.
socket 모듈은 사용 가능하지만 제한적이며 다른 플랫폼과 다르게 동작합니다. Emscripten에서 소켓은 항상 비차단(non-blocking) 방식이며, WebSockets를 통해 TCP를 프록시하기 위해 서버 측의 추가 자바스크립트 코드와 헬퍼가 필요합니다; 자세한 내용은 Emscripten Networking 을 참조하십시오. WASI snapshot preview 1은 기존 파일 디스크립터로부터 생성된 소켓만 허용합니다.
일부 함수는 아무것도 수행하지 않고 미리 정의된 값을 항상 반환하는 스텁(stub)입니다.
파일 기술자, 파일 권한, 파일 소유권 및 링크와 관련된 기능은 제한되어 있으며 일부 작업을 지원하지 않습니다. 예를 들어, WASI는 절대 경로를 포함하는 심볼릭 링크를 허용하지 않습니다.

모바일 플랫폼¶

Android와 iOS는 대부분의 측면에서 POSIX 운영체제입니다. 파일 I/O, 소켓 처리 및 스레딩은 모든 POSIX 운영체제에서 작동하는 방식과 동일하게 동작합니다. 하지만 몇 가지 주요한 차이점이 있습니다.

모바일 플랫폼에서는 Python을 “임베디드” 모드로만 사용할 수 있습니다. Python REPL이 없으며, python 이나 pip 와 같은 별도의 실행 파일을 사용할 수 없습니다. 모바일 앱에 Python 코드를 추가하려면 Python embedding API 를 사용해야 합니다. 자세한 내용은 안드로이드에서 파이썬 사용하기 및 iOS에서 Python 사용하기 를 참조하십시오.
서브 프로세스:
- Android에서 서브 프로세스를 생성하는 것은 가능하지만 공식적으로 지원되지 않습니다. 특히 Android는 System V IPC API의 어떤 부분도 지원하지 않으므로 multiprocessing 을 사용할 수 없습니다.
- iOS 앱은 어떠한 형태의 서브 프로세싱, 멀티프로세싱 또는 프로세스 간 통신(IPC)도 사용할 수 없습니다. 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)은 모바일 플랫폼에서 사용할 수 없습니다.