はじめに

The Python standard library consists of a collection of modules. There are many ways to dissect this collection. Most modules are written in Python, but some are written in C. All can be imported into your program to add functionality. Some modules provide interfaces that are highly specific to Python, like printing a stack trace; some provide interfaces that are specific to particular operating systems, such as access to specific hardware; others provide interfaces that are specific to a particular application domain, like web development. Some modules are available in all versions and ports of Python; others are only available when the underlying system supports or requires them; yet others are available only when a particular configuration option was chosen at the time when Python was compiled and installed.

If you start reading this manual from the start, and skip to the next chapter when you get bored, you will get a reasonable overview of the available modules and application areas that are supported by the Python library. Of course, you don't have to read it like a novel --- you can also browse the table of contents (in front of the manual), or look for a specific function, module or term in the index (in the back). And finally, if you enjoy learning about random subjects, you choose a random page and read a section or two. Regardless of the order in which you read the sections of this manual, it helps to first read Built-in Functions, as the remainder of this section assumes familiarity with this material.

参考

The built-in functions and classes (which can be used without an import statement) are described in Python built-ins reference.

利用可能性について

• 「利用できる環境 : Unix 」の意味はこの関数が Unix システムにあることが多いということです。このことは特定の OS における存在を主張するものではありません。

• 特に記述がない場合、「利用できる環境 : Unix 」と書かれている関数は、 Unix をコアにしているmacOS、iOS、Androidでも利用することができます。

• 利用可能性の注釈に最小カーネルバージョンと最小 libc バージョンの両方が含まれている場合は、両方の条件を満たさなければなりません。例えば、 Availability: Linux >= 3.17 with glibc >= 2.27 という注釈付きの機能には、 Linux 3.17 以上と、 glibc 2.27 以上の両方が必要です。

WebAssembly プラットフォーム

WebAssembly プラットフォームである wasm32-emscripten (Emscripten) と wasm32-wasi (WASI) は、 POSIX API のサブセットを提供します。 WebAssembly ランタイムとブラウザーはサンドボックス化されており、ホストや外部リソースへのアクセスが制限されています。プロセス、スレッド、ネットワーク、シグナル、または他の形のプロセス間通信 (IPC) を使用する標準ライブラリモジュールは、利用不可か、他の Unix ライクなシステムのようには動作しません。ファイル I/O 、ファイルシステム、 Unix の権限関係の機能も制限されています。 Emscripten はブロッキング I/O を許可しません。 sleep() のような他のブロッキング操作は、ブラウザーのイベントループをブロックします。

WebAssembly プラットフォーム上での Python の 性質と振る舞いは、 Emscripten-SDK や WASI-SDK のバージョン、 WASM ランタイム (ブラウザ、 NodeJS 、 wasmtime) 、Python のビルド時フラグによって決まります。 WebAssembly や Emscripten 、 WASI は標準を発展させており、ネットワークなどの機能は将来的にサポートされるかもしれません

ブラウザ上の Python では、ユーザーは Pyodide や PyScript を検討すべきでしょう。 PyScript は、 Pyodide をもとにして構築されており、 Pyodide 自体は CPython や Emscripten 上に構築されています。 Pyodide は、ブラウザの JavaScript と DOM API だけでなく、 JavaScript の XMLHttpRequest や Fetch API による制限されたネットワーク機能へのアクセスを提供します。

• プロセス関連の API は利用不可能か、常にエラーにより失敗します。これには、新しいプロセスを作成 (fork() や execve()) 、プロセスを待機 (waitpid()) 、シグナルを送信 (kill()) 、もしくはプロセスと通信する API が含まれます。 subprocess はインポート可能ですが、機能しません。

• socket モジュールは利用できますが、機能に制限があり、他のプラットフォームとは動作が異なります。 Emscripten ではソケットは常に非ブロッキングで、WebSocket を介して TCP 通信を中継するための JavaScript コードとサーバー側の補助プログラムが別途必要です。 詳しくは Emscripten Networking を参照してください。 WASI snapshot preview 1 では、既存のファイル記述子から作ったソケットのみ使用できます。

• 一部の関数は、何もせず常に決められた値を返すだけのスタブです。

• ファイル記述子、ファイルのアクセス権、ファイルの所有者、リンクに関する関数には制限があり、一部の操作はサポートしていません。 例えば、WASI では絶対ファイル名を使ったシンボリックリンクは許可されません。

モバイルプラットフォーム

Android と iOS は、ほとんどの点で POSIX オペレーティングシステムです。 ファイル I/O、ソケットの操作、スレッドはいずれも他の POSIX オペレーティングシステムと同じように動作します。 ただし、いくつか大きな違いがあります。

• モバイルプラットフォームでは、Python は「組み込み」モードでのみ使用できます。 Python の REPL はなく、python や pip などの独立した実行ファイルも使用できません。 モバイルアプリに Python コードを追加するには、Python の埋め込み API を使用する必要があります。 詳しくは Using Python on Android と Using Python on iOS を参照してください。

• サブプロセス:

  • Android ではサブプロセスを作成できますが、公式にはサポートされていません。 特に、Android は System V IPC API を一切サポートしていないため、multiprocessing は利用できません。

  • iOS アプリでは、サブプロセス、マルチプロセッシング、プロセス間通信はいずれの形式も使用できません。 iOS アプリがサブプロセスを作成しようとすると、作成元のプロセスが動かなくなるかクラッシュします。 iOS アプリは、その目的で用意された iOS 固有の API を除き、他の実行中のアプリケーションを調べたり、それらと通信したりすることはできません。

• モバイルアプリによるシステムリソース (システム時計など) の変更は制限されています。 これらのリソースは 読み取れる 場合が多いものの、変更しようとすると通常は失敗します。

• コンソールの入出力:

  • Android では、ネイティブの stdout と stderr はどこにも接続されていないため、Python はメッセージをシステムログに転送する独自のストリームを設定します。 これらのメッセージは、それぞれ python.stdout と python.stderr というタグで確認できます。

  • iOS アプリで利用できるコンソール出力は限定的です。 stdout と stderr は 存在し、Xcode での実行中は、そこに書き込んだ内容をログで確認できますが、システムログには 記録されません。 アプリをインストールしたユーザーから診断のためにアプリのログを提供してもらっても、stdout や stderr に書き込んだ内容は一切含まれません。

  • モバイルアプリには、利用可能な stdin がまったくありません。 アプリは画面上にキーボードを表示できますが、これはソフトウェアの機能であり、stdin に接続されているわけではありません。

    そのため、コンソールを操作する Python モジュール (curses や readline など) はモバイルプラットフォームでは利用できません。