はじめに¶
Python 標準ライブラリはモジュールの集まりです。 これらのモジュールはさまざまな観点で分類できます。 大部分は Python で書かれていますが、C で書かれたものもあります。 どのモジュールもプログラムにインポートして機能を追加できます。 スタックトレースの表示など Python 固有のインターフェースを提供するものもあれば、特定のハードウェアへのアクセスなど OS 固有のインターフェースを提供するものや、ウェブ開発など特定の応用分野のインターフェースを提供するものもあります。 Python のすべてのバージョンや移植版で利用できるモジュールもあれば、基盤となるシステムがサポートしている場合や必要とする場合にのみ利用できるものもあります。 また、Python のコンパイルとインストールの際に特定の構成オプションを選んだ場合にのみ利用できるモジュールもあります。
このマニュアルを最初から読み始め、飽きたら次の章に進むという読み方でも、Python ライブラリで利用できるモジュールとその応用分野をおおまかに把握できます。 もちろん、小説のように読む 必要はありません。 マニュアルの先頭にある目次を眺めたり、末尾の索引で特定の関数やモジュール、用語を調べたりすることもできます。 また、思いがけない話題について学ぶのが好きなら、適当なページを開いて一節か二節読んでみるのもよいでしょう。 このマニュアルをどの順番で読むにしても、まず 組み込み関数 (built-in function) を読んでおくと役立ちます。 この節の残りの部分は、その内容を理解していることを前提としています。
参考
import 文を使わずに利用できる組み込み関数とクラスは、Python 組み込み機能リファレンス で説明しています。
利用可能性について¶
「利用できる環境 : 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 を使用する必要があります。 詳しくは Android で Python を使う と iOS で Python を使う を参照してください。
サブプロセス:
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など) はモバイルプラットフォームでは利用できません。