初期化 (initialization)、終了処理 (finalization)、スレッド
**********************************************************


インタプリタの初期化と終了処理
==============================

void Py_Initialize()

   Python インタプリタを初期化します。 Python の埋め込みを行うアプリケ
   ーションでは、他のあらゆる Python/C API を使用するよりも前にこの関
   数を呼び出さなければなりません。ただし、 "Py_SetProgramName()",
   "Py_SetPythonHome()", および "Py_SetPath()" は例外です。この関数は
   ロード済みモジュールのテーブル ("sys.modules") を初期化し、基盤とな
   るモジュール群、 "builtins", "__main__", "sys" を生成します。また、
   モジュール検索パス   ("sys.path") も初期化します。 "sys.argv" の設
   定は行いません。設定するには、 "PySys_SetArgvEx()" を使ってください
   。この関数を ("Py_FinalizeEx()" を呼ばずに) 再度呼び出しても何も行
   いません。戻り値はありません。初期化が失敗すれば、それは致命的なエ
   ラーです。

   注釈: Windows では "O_TEXT" から "O_BINARY" へコンソールモードが
     変更さ れますが、これはその C ランタイムを使っているコンソールで
     の Python 以外の使い勝手にも影響を及ぼします。

void Py_InitializeEx(int initsigs)

   *initsigs* に "1" を指定した場合、この関数は "Py_Initialize()" と同
   じように動作します。 *initsigs* に "0" を指定した場合、初期化時のシ
   グナルハンドラの登録をスキップすることができ、これは Python の埋め
   込みで便利でしょう。

int Py_IsInitialized()

   Python インタプリタが初期化済みであれば真(非ゼロ)を、さもなければ偽
   (ゼロ)を返します。"Py_FinalizeEx()" を呼び出した後は、
   "Py_Initialize()" を再び呼び出すまで、この関数は偽を返します。

int Py_FinalizeEx()

   "Py_Initialize()" とそれ以後の Python/C API 関数で行った全ての初期
   化処理を取り消し、最後の "Py_Initialize()"  呼び出し以後に Python
   インタプリタが生成した全てのサブインタプリタ  (sub-interpreter, 下
   記の "Py_NewInterpreter()" を参照) を消去します。 理想的な状況では
   、この関数によって Python インタプリタが確保したメモリは全て解放さ
   れます。 この関数を ("Py_Initialize()" を呼ばずに) 再度呼び出しても
   何も行いません。 通常は返り値は "0" です。終了処理中 (バッファリン
   グされたデータの書き出し) のエラーがあった場合は "-1" が返されます
   。

   この関数が提供されている理由はいくつかあります。Python の埋め込みを
   行っているアプリケーションでは、アプリケーションを再起動することな
   く Python を再起動したいことがあります。また、動的ロード可能イブラ
   リ (あるいは DLL) から Python インタプリタをロードするアプリケーシ
   ョンでは、DLL をアンロードする前に Python が確保したメモリを全て解
   放したいと考えるかもしれません。アプリケーション内で起きているメモ
   リリークを追跡する際に、開発者は Python が確保したメモリをアプリケ
   ーションの終了前に解放させたいと思う場合もあります。

   **バグおよび注意事項:** モジュールやモジュール内のオブジェクトはラ
   ンダムな順番で削除されます。このため、他のオブジェクト(関数オブジェ
   クトも含みます) やモジュールに依存するデストラクタ  ("__del__()" メ
   ソッド) が失敗してしまうことがあります。動的にロードされるようにな
   っている拡張モジュールが Python によってロードされていた場合、アン
   ロードされません。 Python が確保したメモリがわずかながら解放されな
   いかもしれません (メモリリークを発見したら、どうか報告してください)
   。オブジェクト間の循環参照に捕捉されているメモリは解放されないこと
   があります。拡張モジュールが確保したメモリは解放されないことがあり
   ます。拡張モジュールによっては、初期化ルーチンを 2 度以上呼び出すと
   正しく動作しないことがあります。こうした状況は、 "Py_Initialize()"
   や "Py_FinalizeEx()" を 2 度以上呼び出すと起こり得ます。

   バージョン 3.6 で追加.

void Py_Finalize()

   この関数は "Py_FinalizeEx()" の後方互換性バージョンで、戻り値があり
   ません。


プロセスワイドのパラメータ
==========================

int Py_SetStandardStreamEncoding(const char *encoding, const char *errors)

   もし "Py_Initialize()" が呼ばれるなら、この関数はその前に呼ばなけれ
   ばなりません。標準の IO において、どのエンコーディングおよびどんな
   エラー処理を使うかを、 "str.encode()" と同様の意味で指定します。

   これは、環境変数が働かない時に "PYTHONIOENCODING" の値を上書きし、
   埋め込みコードが IO エンコーディングをコントロールできるようにしま
   す。

   "encoding" と "errors" のどちらかまたは両方を NULL にすることで、
   "PYTHONIOENCODING" とデフォルト値のどちらかまたは両方を使うことがで
   きます (他の設定に依存します)。

   この設定 (あるいは他の設定) に関わらず、 "sys.stderr" は常に
   "backslashreplace" エラーハンドラを使うことに注意してください。

   "Py_FinalizeEx()" を呼び出した場合は、"Py_Initialize()" を呼び出す
   前に、この関数を再度呼び出す必要があるでしょう。

   成功したら "0" を、エラーの場合は "0" でない値を返します (例えば、
   インタプリタが初期化された後に、この関数が呼び出された場合)。

   バージョン 3.4 で追加.

void Py_SetProgramName(wchar_t *name)

   この関数を呼び出すなら、最初に "Py_Initialize()" を呼び出すよりも前
   に呼び出さなければなりません。この関数はインタプリタにプログラムの
   "main()" 関数に指定した "argv[0]" 引数の値を教えます (ワイドキャラ
   クタに変換されます)。この引数値は、 "Py_GetPath()" や、以下に示すそ
   の他の関数が、インタプリタの実行可能形式から Python ランタイムライ
   ブラリへの相対パスを取得するために使われます。デフォルトの値は
   "'python'" です。引数はゼロ終端されたワイドキャラクタ文字列で、静的
   な記憶領域に入っていなければならず、その内容はプログラムの実行中に
   変更してはなりません。 Python インタプリタ内のコードで、この記憶領
   域の内容を変更するものは一切ありません。

   バイト文字列を "wchar_*" 文字列にデコードするには
   "Py_DecodeLocale()" を使ってください。

wchar* Py_GetProgramName()

   "Py_SetProgramName()" で設定されたプログラム名か、デフォルトのプロ
   グラム名を返します。関数が返す文字列ポインタは静的な記憶領域を返し
   ます。関数の呼び出し側はこの値を変更できません。

wchar_t* Py_GetPrefix()

   プラットフォーム非依存のファイル群がインストールされている場所であ
   る *prefix* を返します。この値は "Py_SetProgramName()" でセットされ
   たプログラム名やいくつかの環境変数をもとに、数々の複雑な規則から導
   出されます。例えば、プログラム名が "'/usr/local/bin/python'" の場合
   、prefix は "'/usr/local'" になります。関数が返す文字列ポインタは静
   的な記憶領域を返します; 関数の呼び出し側はこの値を変更できません。
   この値はトップレベルの "Makefile" に指定されている変数 **prefix**
   や、ビルド値に **configure** スクリプトに指定した "--prefix" 引数に
   対応しています。この値は Python コードからは "sys.prefix" として利
   用できます。これはUnixでのみ有用です。次に説明する関数も参照してく
   ださい。

wchar_t* Py_GetExecPrefix()

   プラットフォーム *依存* のファイルがインストールされている場所であ
   る *exec-prefix* を返します。この値は "Py_SetProgramName()" でセッ
   トされたプログラム名やいくつかの環境変数をもとに、数々の複雑な規則
   から導出されます。例えば、プログラム名が "'/usr/local/bin/python'"
   の場合、exec-prefix は "'/usr/local'" になります。関数が返す文字列
   ポインタは静的な記憶領域を返します; 関数の呼び出し側はこの値を変更
   できません。この値はトップレベルの "Makefile" に指定されている変数
   **exec_prefix** や、ビルド値に **configure** スクリプトに指定した "
   --exec-prefix" 引数に対応しています。この値は Python コードからは
   "sys.exec_prefix" として利用できます。 Unixのみで有用です。

   背景: プラットフォーム依存のファイル (実行形式や共有ライブラリ) が
   別のディレクトリツリー内にインストールされている場合、 exec-prefix
   は prefix と異なります。典型的なインストール形態では、プラットフォ
   ーム非依存のファイルが "/usr/local" に収められる一方、プラットフォ
   ーム依存のファイルは "/usr/local/plat" サブツリーに収められます。

   一般的に、プラットフォームとは、ハードウェアとソフトウェアファミリ
   の組み合わせを指します。例えば、Solaris 2.x を動作させている Sparc
   マシンは全て同じプラットフォームであるとみなしますが、Solaris 2.x
   を動作させている Intel マシンは違うプラットフォームになりますし、同
   じ Intel マシンでも Linux を動作させているならまた別のプラットフォ
   ームです。一般的には、同じオペレーティングシステムでも、メジャーリ
   ビジョンの違うものは異なるプラットフォームです。非 Unix のオペレー
   ティングシステムの場合は話はまた別です; 非 Unix のシステムでは、イ
   ンストール方法はとても異なっていて、prefix や exec-prefix には意味
   がなく、空文字列が設定されています。コンパイル済みの Python バイト
   コードはプラットフォームに依存しないので注意してください (ただし、
   どのバージョンの Python でコンパイルされたかには依存します!)。

   システム管理者は、 **mount** や **automount** プログラムを使って、
   各プラットフォーム用の "/usr/local/plat" を異なったファイルシステム
   に置き、プラットフォーム間で "/usr/local" を共有するための設定方法
   を知っているでしょう。

wchar_t* Py_GetProgramFullPath()

   Python 実行可能形式の完全なプログラム名を返します; この値はデフォル
   トのモジュール検索パスを (前述の "Py_SetProgramName()"  で設定され
   た) プログラム名から導出する際に副作用的に計算されます。関数が返す
   文字列ポインタは静的な記憶領域を返します; 関数の呼び出し側はこの値
   を変更できません。この値は Python コードからは "sys.executable" と
   して利用できます。

wchar_t* Py_GetPath()

   デフォルトのモジュール検索パスを返します; パスは (上の
   "Py_SetProgramName()" で設定された) プログラム名と、いくつかの環境
   変数から計算されます。戻り値となる文字列は、プラットフォーム依存の
   パス区切り文字で分割された一連のディレクトリ名からなります。区切り
   文字は Unix と Mac OS X では "':'", Windows では "';'" です。関数が
   返す文字列ポインタは静的な記憶領域を返します; 関数の呼び出し側はこ
   の値を変更できません。 "sys.path" はインタプリタによってこの値で初
   期化され、その後にモジュールをロードする際の検索パスを変更するため
   に修正することが可能で、たいていそうされます。

void Py_SetPath(const wchar_t *)

   デフォルトのモジュール検索パスを設定します。この関数が
   "Py_Initialize()" より前に呼び出された場合、 "Py_GetPath()" はデフ
   ォルトの検索パスを計算しようとせず、代わりにこの関数が与えた検索パ
   スを返します。これは、 Python がアプリケーションに組み込まれていて
   、そのアプリケーションが全てのモジュールの場所を完全に把握している
   ときに便利です。パスはプラットフォーム依存の区切り文字で分割されて
   いる必要があります。区切り文字は Unix と Mac OS X では "':'" 、
   Windows では "';'" です。

   また、この関数は "sys.executable" に特に加工されていないプログラム
   名 ("Py_SetProgramName()" を参照) をセットし、 "sys.prefix" と
   "sys.exec_prefix" に空文字列をセットします。 "Py_Initialize()" が呼
   び出された後で、これらの値を変更する必要がある場合は、呼び出し側の
   責任で行います。

   バイト文字列を "wchar_*" 文字列にデコードするには
   "Py_DecodeLocale()" を使ってください。

   パス引数は内部でコピーされます。したがって、呼び出し完了後に呼び出
   し元は引数を解放できます。

const char* Py_GetVersion()

   Python インタプリタのバージョンを返します。バージョンは、次のような
   形式の文字列です

      "3.0a5+ (py3k:63103M, May 12 2008, 00:53:55) \n[GCC 4.2.3]"

   第一ワード (最初のスペース文字まで) は、現在の Python のバージョン
   です; 最初の三文字は、ピリオドで区切られたメジャーバージョンとマイ
   ナーバージョンです。関数が返す文字列ポインタは静的な記憶領域を返し
   ます; 関数の呼び出し側はこの値を変更できません。この値は Python コ
   ードからは "sys.version" として利用できます。

const char* Py_GetPlatform()

   現在のプラットフォームのプラットフォーム識別文字列を返します。Unix
   では、オペレーティングシステムの "公式の" 名前を小文字に変換し、後
   ろにメジャーリビジョン番号を付けた構成になっています。例えば
   Solaris 2.x は、SunOS 5.x, としても知られていますが、"'sunos5'" に
   なります。Mac OS X では "'darwin'" です。Windows では "'win'" です
   。関数が返す文字列ポインタは静的な記憶領域を返します; 関数の呼び出
   し側はこの値を変更できません。この値は Python コードからは
   "sys.platform" として利用できます。

const char* Py_GetCopyright()

   現在の Python バージョンに対する公式の著作権表示文字列を返します。
   例えば

   "'Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam'"

   関数が返す文字列ポインタは静的な記憶領域を返します; 関数の呼び出し
   側はこの値を変更できません。この値は Python コードからは
   "sys.copyright" として利用できます。

const char* Py_GetCompiler()

   現在使っているバージョンの Python をビルドする際に用いたコンパイラ
   を示す文字列を、角括弧で囲った文字列を返します。例えば:

      "[GCC 2.7.2.2]"

   関数が返す文字列ポインタは静的な記憶領域を返します; 関数の呼び出し
   側はこの値を変更できません。この値は Python コードからは
   "sys.version" の一部として取り出せます。

const char* Py_GetBuildInfo()

   現在使っている Python インタプリタインスタンスの、シーケンス番号と
   ビルド日時に関する情報を返します。例えば

      "#67, Aug  1 1997, 22:34:28"

   関数が返す文字列ポインタは静的な記憶領域を返します; 関数の呼び出し
   側はこの値を変更できません。この値は Python コードからは
   "sys.version" の一部として取り出せます。

void PySys_SetArgvEx(int argc, wchar_t **argv, int updatepath)

   *argc* および *argv* に基づいて "sys.argv" を設定します。これらの引
   数はプログラムの "main()" に渡した引数に似ていますが、最初の要素が
   Python インタプリタの宿主となっている実行形式の名前ではなく、実行さ
   れるスクリプト名を参照しなければならない点が違います。実行するスク
   リプトがない場合、 *argv* の最初の要素は空文字列にしてもかまいませ
   ん。この関数が "sys.argv" の初期化に失敗した場合、致命的エラーを
   "Py_FatalError()" で知らせます。

   *updatepath* が 0 の場合、ここまでの動作がこの関数がすることの全て
   です。 *updatepath* が 0 でない場合、この関数は "sys.path" を以下の
   アルゴリズムに基づいて修正します:

   * 存在するスクリプトの名前が "argv[0]" に渡された場合、そのスクリ
     プ トがある場所の絶対パスを "sys.path" の先頭に追加します。

   * それ以外の場合 (*argc* が "0" だったり、 "argv[0]" が存在するフ
     ァ イル名を指していない場合)、 "sys.path" の先頭に空の文字列を追
     加し ます。 これは現在の作業ディレクトリ (""."") を先頭に追加する
     のと 同じです。

   バイト文字列を "wchar_*" 文字列にデコードするには
   "Py_DecodeLocale()" を使ってください。

   注釈: 単一のスクリプトを実行する以外の目的でPython インタプリタを
     埋め込 んでいるアプリケーションでは、 *updatepath* に "0" を渡し
     て、必要 な場合は自分で "sys.path" を更新することをおすすめします
     。 CVE-2008-5983 を参照してください。3.1.3 より前のバージョンでは
     、 "PySys_SetArgv()" の呼び出しが完了した後に "sys.path" の先頭の
     要 素を取り出すことで、同じ効果が得られます。例えばこのように使い
     ま す:

        PyRun_SimpleString("import sys; sys.path.pop(0)\n");

   バージョン 3.1.3 で追加.

void PySys_SetArgv(int argc, wchar_t **argv)

   この関数は、 **python** インタプリタが "-I" オプション付きで実行さ
   れている場合を除き "PySys_SetArgvEx()" の *updatepath* に "1" を設
   定したのと同じように動作します。

   バイト文字列を "wchar_*" 文字列にデコードするには
   "Py_DecodeLocale()" を使ってください。

   バージョン 3.4 で変更: *updatepath* の値は "-I" オプションに依存し
   ます。

void Py_SetPythonHome(wchar_t *home)

   Python の標準ライブラリがある、デフォルトの "home" ディレクトリを設
   定します。引数の文字列の意味については "PYTHONHOME" を参照してくだ
   さい。

   引数は静的なストレージに置かれてプログラム実行中に書き換えられない
   ようなゼロ終端の文字列であるべきです。Python インタプリタはこのスト
   レージの内容を変更しません。

   バイト文字列を "wchar_*" 文字列にデコードするには
   "Py_DecodeLocale()" を使ってください。

w_char* Py_GetPythonHome()

   前回の "Py_SetPythonHome()" 呼び出しで設定されたデフォルトの "home"
   か、 "PYTHONHOME" 環境変数が設定されていればその値を返します。


スレッド状態 (thread state) とグローバルインタプリタロック (global interpreter lock)
====================================================================================

Python インタプリタは完全にはスレッドセーフではありません。マルチスレ
ッドの Python プログラムをサポートするために、グローバルインタプリタロ
ック(*global interpreter lock*, *GIL*) と呼ばれるグローバルなロックが
存在していて、現在のスレッドが Python オブジェクトに安全にアクセスする
前に必ずロックを獲得しなければならなくなっています。ロック機構がなけれ
ば、単純な操作でさえ、マルチスレッドプログラムの実行に問題を引き起こす
可能性があります。たとえば、二つのスレッドが同じオブジェクトの参照カウ
ントを同時にインクリメントすると、結果的に参照カウントは二回でなく一回
だけしかインクリメントされないかもしれません。

このため、 *GIL* を獲得したスレッドだけが Python オブジェクトを操作し
たり、 Python/C API 関数を呼び出したりできるというルールがあります。並
行処理をエミュレートするために、インタプリタは定期的にロックを解放した
り獲得したりします。 ("sys.setswitchinterval()" を参照) このロックはブ
ロックが起こりうる I/O 操作の付近でも解放・獲得され、 I/O を要求するス
レッドが I/O 操作の完了を待つ間、他のスレッドが動作できるようにしてい
ます。

Python インタプリタはスレッドごとに必要な情報を "PyThreadState" と呼ば
れるデータ構造の中に保存します。そしてグローバル変数として現在の
"PyThreadState" を指すポインタを1つ持ちます。このグローバル変数は
"PyThreadState_Get()" を使って取得できます。


拡張コード内で GIL を解放する
-----------------------------

*GIL* を操作するほとんどのコードは、次のような単純な構造になります:

   Save the thread state in a local variable.
   Release the global interpreter lock.
   ... Do some blocking I/O operation ...
   Reacquire the global interpreter lock.
   Restore the thread state from the local variable.

この構造は非常に一般的なので、作業を単純にするために2つのマクロが用意
されています:

   Py_BEGIN_ALLOW_THREADS
   ... Do some blocking I/O operation ...
   Py_END_ALLOW_THREADS

"Py_BEGIN_ALLOW_THREADS" マクロは新たなブロックを開始し、隠しローカル
変数を宣言します; "Py_END_ALLOW_THREADS" はブロックを閉じます。 Python
をスレッドサポートなしでコンパイルしたときでもこの2つのマクロは利用可
能です (単に、空行に展開されます)。

スレッドサポートが有効になっている場合、上記のブロックは以下のようなコ
ードに展開されます:

   PyThreadState *_save;

   _save = PyEval_SaveThread();
   ...Do some blocking I/O operation...
   PyEval_RestoreThread(_save);

これらの関数の動作を説明します。GIL は現在のスレッド状態を指すポインタ
を保護するために使われます。ロックを解放してスレッド状態を退避する際、
ロックを解放する前に現在のスレッド状態ポインタを取得しておかなければな
りません (他のスレッドがすぐさまロックを獲得して、自らのスレッド状態を
グローバル変数に保存してしまうかもしれないからです)。逆に、ロックを獲
得してスレッド状態を復帰する際には、グローバル変数にスレッド状態ポイン
タを保存する前にロックを獲得しておかなければなりません。

注釈: GIL を解放するのはほとんどがシステムのI/O関数を呼び出す時です
  が、メ モリバッファに対する圧縮や暗号化のように、 Python のオブジェ
  クトにア クセスしない長時間かかる計算処理を呼び出すときも GIL を解放
  すること は有益です。例えば、 "zlib" や "hashlib" モジュールは圧縮や
  ハッシュ 計算の前に GIL を解放します。


Python 以外で作られたスレッド
-----------------------------

Python API を通して作られたスレッド ("threading" モジュールなど) では
自動的にスレッド状態が割り当てられて、上記のコードは正しく動きます。し
かし、(自前でスレッド管理を行う外部のライブラリなどにより)C言語でスレ
ッドを生成した場合、そのスレッドには GIL がなく、スレッド状態データ構
造体もないことに注意する必要があります。

このようなスレッドから Python コードを呼び出す必要がある場合 (外部のラ
イブラリからコールバックするAPIなどがよくある例です)、Python/C API を
呼び出す前に、スレッド状態データ構造体を生成し、GIL を獲得し、スレッド
状態ポインタを保存することで、スレッドをインタプリタに登録しなければな
りません。スレッドが作業を終えたら、スレッド状態ポインタをリセットして
、ロックを解放し、最後にスレッド状態データ構造体のメモリを解放しなけれ
ばなりません。

"PyGILState_Ensure()" と "PyGILState_Release()" はこの処理を自動的に行
います。 Cのスレッドから Python を呼び出す典型的な方法は以下のとおりで
す:

   PyGILState_STATE gstate;
   gstate = PyGILState_Ensure();

   /* Perform Python actions here. */
   result = CallSomeFunction();
   /* evaluate result or handle exception */

   /* Release the thread. No Python API allowed beyond this point. */
   PyGILState_Release(gstate);

"PyGILState_*()" 関数は、("Py_Initialize()" によって自動的に作られる)
グローバルインタプリタ1つだけが存在すると仮定する事に気をつけて下さい
。 Python は ("Py_NewInterpreter()" を使って) 追加のインタプリタを作成
できることに変わりはありませんが、複数インタプリタと "PyGILState_*()"
API を混ぜて使うことはサポートされていません。

注意しないといけないもう一つの重要な点は、 C の "fork()" を呼び出した
時の動作です。ほとんどの "fork()" を持っているシステムでは、fork され
たプロセスには fork を実行したスレッドしか存在しません。これは、別のス
レッドに取得されたロックがずっと解放されないことを意味します。 Python
は fork する前にロックを取得し、その後に fork を解放することでこの
"os.fork()" の問題を解決しています。加えて、子プロセスではすべての
Lock オブジェクト をリセットします。 Python を拡張したり埋め込んだりし
ている場合、 Python に fork 前に取得したり fork 後に解放しなければなら
ない追加の (Python 以外の) ロックを Python に教える手段がありません。
Python と同じことを実現するには、 "pthread_atfork()" のようなOSの機能
を使う必要があります。加えて、Python を拡張したり埋め込んだりしている
ときに、 "os.fork()" を通してではなく直接 "fork()" を呼び出すと、fork
後に失われるスレッドに取得されていた Python の内部ロックのためにデッド
ロックが発生するかもしれません。 "PyOS_AfterFork()" は必要なロックのリ
セットを試みますが、いつでもそれが可能とは限りません。


高レベルAPI
-----------

C拡張を書いたりPythonインタプリタを埋め込むときに最も一般的に使われる
型や関数は次のとおりです:

PyInterpreterState

   このデータ構造体は、協調動作する多数のスレッド間で共有されている状
   態を表現します。同じインタプリタに属するスレッドはモジュール管理情
   報やその他いくつかの内部的な情報を共有しています。この構造体には公
   開 (public) のメンバはありません。

   異なるインタプリタに属するスレッド間では、利用可能なメモリ、開かれ
   ているファイルデスクリプタなどといったプロセス状態を除いて、初期状
   態では何も共有されていません。GILもまた、スレッドがどのインタプリタ
   に属しているかに関わらずすべてのスレッドで共有されています。

PyThreadState

   単一のスレッドの状態を表現する表現するデータ構造体です。スレッドの
   インタプリタ状態を指すポインタ "PyInterpreterState *" "interp" だけ
   が公開されているデータメンバです。

void PyEval_InitThreads()

   GIL を初期化し、獲得します。この関数は、主スレッドが第二のスレッド
   を生成する以前や、 "PyEval_ReleaseThread(tstate)" といった他のスレ
   ッド操作に入るよりも前に呼び出されるようにしておかなければなりませ
   ん。 "PyEval_SaveThread()", "PyEval_RestoreThread()" の前に呼び出す
   必要はありません。

   二度目に呼び出すと何も行いません。

   バージョン 3.2 で変更: この関数は "Py_Initialize()" より前に呼び出
   すことができなくなりました。

   注釈: メインスレッドだけが存在しているとき、 GIL 操作は必要ありま
     せん。 (ほとんどの Python プログラムはスレッドを使わないので) こ
     れはよく ある状況であり、ロック操作はインタプリタの動作を少しだけ
     遅くしま す。なので、ロックは最初には作成されません。これはロック
     を獲得し ているのと同じ状態になります: スレッドが 1 つしかないと
     き、オブジ ェクトへの全てのアクセスは安全です。またこれらのことか
     ら、この関 数がグローバルインタプリタロックを初期化するときは、そ
     の取得も行 います。 Python の "_thread" モジュールは新しいスレッ
     ドを作成する 前に、ロックが既にあるのかロックはまだ作成されていな
     いのか知るた めに、  "PyEval_InitThreads()" を呼び出します。呼び
     出しが返ってき たとき、ロックが作成されており、呼び出したスレッド
     がそれを獲得し たことが保証されます。(どんなスレッドであれ) どの
     スレッドが現在グ ローバルインタプリタロックを持っているか分からな
     いときに、この関 数を呼び出すのは安全では **ありません**。この関
     数は、コンパイル時 にスレッドサポートが無効にされているときは利用
     できません。

int PyEval_ThreadsInitialized()

   "PyEval_InitThreads()" をすでに呼び出している場合は真 (非ゼロ) を返
   します。この関数は、GILを獲得せずに呼び出すことができますので、シン
   グルスレッドで実行している場合にはロック関連のAPI呼び出しを避けるた
   めに使うことができます。この関数はコンパイル時にスレッドサポートを
   無効化すると利用できません。

PyThreadState* PyEval_SaveThread()

   (GIL が生成されていて、スレッドサポートが有効の場合) GILを解放して
   、スレッド状態を *NULL* にし、以前のスレッド状態 (*NULL* にはなりま
   せん) を返します。ロックがすでに生成されている場合、現在のスレッド
   がロックを獲得していなければなりません。(この関数はコンパイル時にス
   レッドサポートが無効にされていても利用できます。)

void PyEval_RestoreThread(PyThreadState *tstate)

   (GIL が生成されていて、スレッドサポートが有効の場合) GIL を獲得して
   、現在のスレッド状態を *tstate* に設定します。*tstate* は *NULL* で
   あってはなりません。GIL が生成されていて、この関数を呼び出したスレ
   ッドがすでにロックを獲得している場合、デッドロックに陥ります。(この
   関数はコンパイル時にスレッドサポートが無効にされていても利用できま
   す。)

PyThreadState* PyThreadState_Get()

   現在のスレッド状態を返します。GIL を保持していなければなりません。
   現在のスレッド状態が *NULL* なら、(呼び出し側が *NULL* チェックをし
   なくてすむように) この関数は致命的エラーを起こすようになっています
   。

PyThreadState* PyThreadState_Swap(PyThreadState *tstate)

   現在のスレッド状態を *tstate* に指定したスレッド状態と入れ変えます
   。*tstate* は *NULL* の場合があります。GIL を保持していなければなら
   ず、解放しません。

void PyEval_ReInitThreads()

   この関数は "PyOS_AfterFork()" から呼び出され、新しい子プロセスが、
   子プロセス内で実行していないスレッドが持っているロックを持たないよ
   うにします。

以下の関数はスレッドローカルストレージを利用していて、サブインタプリタ
との互換性がありません:

PyGILState_STATE PyGILState_Ensure()

   Pythonの状態やGILに関わらず、実行中スレッドでPython C APIの呼び出し
   が可能となるようにします。この関数はスレッド内で何度でも呼び出すこ
   とができますが、必ず全ての呼び出しに対応して "PyGILState_Release()"
   を呼び出す必要があります。通常、 "PyGILState_Ensure()" 呼び出しと
   "PyGILState_Release()" 呼び出しの間でこれ以外のスレッド関連API を使
   用することができますが、Release()の前にスレッド状態は復元されていな
   ければなりません。例えば、通常の "Py_BEGIN_ALLOW_THREADS" マクロと
   "Py_END_ALLOW_THREADS" は使用することができます。

   戻り値は "PyGILState_Ensure()" 呼び出し時のスレッド状態を隠蔽した"
   ハンドル"で、 "PyGILState_Release()" に渡してPythonを同じ状態に保た
   なければなりません。再起呼び出しも可能ですが、ハンドルを共有するこ
   とは *できません* - それぞれの "PyGILState_Ensure()" 呼び出しでハン
   ドルを保存し、対応する "PyGILState_Release()" 呼び出しで渡してくだ
   さい。

   関数から復帰したとき、実行中のスレッドはGILを所有していて、任意の
   Python コードを実行できます。処理の失敗は致命的なエラーです。

void PyGILState_Release(PyGILState_STATE)

   獲得したすべてのリソースを解放します。この関数を呼び出すと、Python
   の状態は対応する "PyGILState_Ensure()" を呼び出す前と同じとなります
   (通常、この状態は呼び出し元でははわかりませんので、GILState APIを利
   用するようにしてください)。

   "PyGILState_Ensure()" を呼び出す場合は、必ず同一スレッド内で対応す
   る "PyGILState_Release()" を呼び出してください。

PyThreadState* PyGILState_GetThisThreadState()

   このスレッドの現在のスレッドの状態を取得します。これまで現在のスレ
   ッドで GILState API を使ったことが無い場合は、"NULL" が返ります。メ
   インスレッドで自身のスレッド状態に関する呼び出しを全くしないとして
   も、メインスレッドは常にスレッド状態の情報を持っていることに注意し
   てください。こうなっている目的は主にヘルパ機能もしくは診断機能のた
   めです。

int PyGILState_Check()

   現在のスレッドが GILを保持しているならば "1" を、そうでなければ "0"
   を返します。この関数はいつでもどのスレッドからでも呼び出すことがで
   きます。 Python スレッドの状態が初期化されており、現在 GIL を保持し
   ている場合にのみ "1" を返します。これは主にヘルパー/診断用の関数で
   す。この関数は、例えばコールバックのコンテキストやメモリ割り当て機
   能で有益でしょう。なぜなら、 GIL がロックされていると知っていれば、
   呼び出し元は sensitive な行動を実行することができ、そうでなければ異
   なるやりかたで振る舞うことができるからです。

   バージョン 3.4 で追加.

以下のマクロは、通常末尾にセミコロンを付けずに使います; Python ソース
配布物内の使用例を見てください。

Py_BEGIN_ALLOW_THREADS

   このマクロを展開すると "{ PyThreadState *_save; _save =
   PyEval_SaveThread();" になります。マクロに開き波括弧が入っているこ
   とに注意してください; この波括弧は後で "Py_END_ALLOW_THREADS" マク
   ロと対応させなければなりません。マクロについての詳しい議論は上記を
   参照してください。コンパイル時にスレッドサポートが無効化されている
   と何も行いません。

Py_END_ALLOW_THREADS

   このマクロを展開すると "PyEval_RestoreThread(_save); }" になります
   。マクロに開き波括弧が入っていることに注意してください; この波括弧
   は事前の "Py_BEGIN_ALLOW_THREADS" マクロと対応していなければなりま
   せん。マクロについての詳しい議論は上記を参照してください。コンパイ
   ル時にスレッドサポートが無効化されていると何も行いません。

Py_BLOCK_THREADS

   このマクロを展開すると "PyEval_RestoreThread(_save);" になります:
   閉じ波括弧のない "Py_END_ALLOW_THREADS" と同じです。コンパイル時に
   スレッドサポートが無効化されていると何も行いません。

Py_UNBLOCK_THREADS

   このマクロを展開すると "_save = PyEval_SaveThread();" になります:
   開き波括弧のない "Py_BEGIN_ALLOW_THREADS" と同じです。コンパイル時
   にスレッドサポートが無効化されていると何も行いません。


低レベルAPI
-----------

以下の全ての関数はコンパイル時にスレッドサポートが有効になっている時だ
け利用でき、呼び出すのはGILがすでに作成されている場合だけにしなくては
なりません。

PyInterpreterState* PyInterpreterState_New()

   新しいインタプリタ状態オブジェクトを生成します。GIL を保持しておく
   必要はありませんが、この関数を次々に呼び出す必要がある場合には保持
   しておいたほうがよいでしょう。

void PyInterpreterState_Clear(PyInterpreterState *interp)

   インタプリタ状態オブジェクト内の全ての情報をリセットします。GIL を
   保持していなければなりません。

void PyInterpreterState_Delete(PyInterpreterState *interp)

   インタプリタ状態オブジェクトを破壊します。GIL を保持しておく必要は
   ありません。インタプリタ状態は "PyInterpreterState_Clear()" であら
   かじめリセットしておかなければなりません。

PyThreadState* PyThreadState_New(PyInterpreterState *interp)

   指定したインタプリタオブジェクトに属する新たなスレッド状態オブジェ
   クトを生成します。GIL を保持しておく必要はありませんが、この関数を
   次々に呼び出す必要がある場合には保持しておいたほうがよいでしょう。

void PyThreadState_Clear(PyThreadState *tstate)

   スレッド状態オブジェクト内の全ての情報をリセットします。GIL を保持
   していなければなりません。

void PyThreadState_Delete(PyThreadState *tstate)

   スレッド状態オブジェクトを破壊します。GIL を保持する必要はありませ
   ん。スレッド状態は "PyThreadState_Clear()" であらかじめリセットして
   おかなければなりません。

PyObject* PyThreadState_GetDict()
    *Return value: Borrowed reference.*

   拡張モジュールがスレッド固有の状態情報を保存できるような辞書を返し
   ます。各々の拡張モジュールが辞書に状態情報を保存するためには唯一の
   キーを使わなければなりません。現在のスレッド状態がない時にこの関数
   を呼び出してもかまいません。この関数が *NULL* を返す場合、例外はま
   ったく送出されず、呼び出し側は現在のスレッド状態が利用できないと考
   えなければなりません。

int PyThreadState_SetAsyncExc(long id, PyObject *exc)

   スレッド内で非同期的に例外を送出します。 *id* 引数はターゲットとな
   るスレッドのスレッド id です; *exc* は送出する例外オブジェクトです
   。この関数は *exc* に対する参照を一切盗み取りません。安直な間違いを
   防ぐため、この関数を呼び出すには独自に C 拡張モジュールを書かなけれ
   ばなりません。 GIL を保持した状態で呼び出さなければなりません。状態
   が変更されたスレッドの数を返します; 通常は 1 ですが、スレッドが見付
   からなかった場合は 0 になることもあります。 *exc* が "NULL" の場合
   は、このスレッドのまだ送出されていない例外は (何であれ) 消去されま
   す。この場合は例外を送出しません。

void PyEval_AcquireThread(PyThreadState *tstate)

   GIL を獲得し、現在のスレッド状態を *tstate* に設定します。 *tstate*
   は *NULL* であってはなりません。ロックはあらかじめ作成されていなけ
   ればなりません。この関数を呼び出したスレッドがすでにロックを獲得し
   ている場合、デッドロックに陥ります。

   "PyEval_RestoreThread()" はいつでも (スレッドサポートが有効でないと
   きやスレッドが初期化されたいないときでさえ) 利用可能な高レベル関数
   です。

void PyEval_ReleaseThread(PyThreadState *tstate)

   現在のスレッド状態をリセットして *NULL* にし、GIL を解放します。ロ
   ックはあらかじめ作成されていなければならず、かつ現在のスレッドが保
   持していなければなりません。*tstate* は *NULL* であってはなりません
   が、その値が現在のスレッド状態を表現しているかどうかを調べるために
   だけ使われます --- もしそうでなければ、致命的エラーが報告されます。

   "PyEval_SaveThread()" はより高レベルな関数で常に(スレッドサポートが
   無効な場合やスレッドが初期化されていない場合でも)利用できます。

void PyEval_AcquireLock()

   GILを獲得します。ロックは前もって作成されていなければなりません。こ
   の関数を呼び出したスレッドがすでにロックを獲得している場合、デッド
   ロックに陥ります。

   バージョン 3.2 で非推奨: この関数は現在のスレッドの状態を更新しませ
   ん。代わりに "PyEval_RestoreThread()" もしくは
   "PyEval_AcquireThread()" を使用してください。

void PyEval_ReleaseLock()

   GILを解放します。ロックは前もって作成されていなければなりません。

   バージョン 3.2 で非推奨: この関数は現在のスレッドの状態を更新しませ
   ん。代わりに "PyEval_SaveThread()" もしくは
   "PyEval_ReleaseThread()" を使用してください。


サブインタプリタサポート
========================

ほとんどの場合は埋め込む Python インタプリタは1つだけですが、いくつか
の場合に同一プロセス内、あるいは同一スレッド内で、複数の独立したインタ
プリタを作成する必要があります。サブインタプリタはこれを可能にします。
"PyThreadState_Swap()" 関数を使ってサブインタプリタを切り替えることが
できます。以下の関数を使ってサブインタプリタの作成と削除を行えます:

PyThreadState* Py_NewInterpreter()

   新しいサブインタプリタ (sub-interpreter) を生成します。サブインタプ
   リタとは、(ほぼ完全に) 個別に分割された Python コードの実行環境です
   。特に、新しいサブインタプリタは、 import されるモジュール全てにつ
   いて個別のバージョンを持ち、これには基盤となるモジュール
   "builtins", "__main__" および "sys" も含まれます。ロード済みのモジ
   ュールからなるテーブル ("sys.modules")  およびモジュール検索パス
   ("sys.path") もサブインタプリタ毎に別個のものになります。新たなサブ
   インタプリタ環境には "sys.argv" 変数がありません。また、サブインタ
   プリタは新たな標準 I/O ストリーム "sys.stdin", "sys.stdout",
   "sys.stderr" を持ちます (とはいえ、これらのストリームは根底にある同
   じファイル記述子を参照しています)。

   戻り値は、新たなサブインタプリタが生成したスレッド状態 (thread
   state) オブジェクトのうち、最初のものを指しています。このスレッド状
   態が現在のスレッド状態 (current thread state) になります。実際のス
   レッドが生成されるわけではないので注意してください; 下記のスレッド
   状態に関する議論を参照してください。新たなインタプリタの生成に失敗
   すると、*NULL* を返します; 例外状態はセットされませんが、これは例外
   状態が現在のスレッド状態に保存されることになっていて、現在のスレッ
   ド状態なるものが存在しないことがあるからです。(他の Python/C API 関
   数のように、この関数を呼び出す前にはGILが保持されていなければならず
   、関数が処理を戻した際にも保持されたままになります; しかし、他の
   Python/C API 関数とは違い、関数から戻ったときの現在のスレッド状態が
   関数に入るときと同じとは限らないので注意してください。)

   拡張モジュールは以下のような形で (サブ) インタプリタ間で共有されま
   す: ある特定の拡張モジュールを最初に import すると、モジュールを通
   常通りに初期化し、そのモジュールの辞書の (浅い) コピーをしまい込ん
   でおきます。他の (サブ) インタプリタが同じ拡張モジュールを import
   すると、新たなモジュールを初期化し、先ほどのコピーの内容で辞書の値
   を埋めます; 拡張モジュールの "init" 関数は呼び出されません。この挙
   動は、 "Py_FinalizeEx()" および "Py_Initialize()" を呼び出してイン
   タプリタを完全に再初期化した後に拡張モジュールを import した際の挙
   動とは異なるので注意してください; 再初期化後に import を行うと、拡
   張モジュールの "initmodule" は再度 *呼び出されます* 。

void Py_EndInterpreter(PyThreadState *tstate)

   指定されたスレッド状態 *tstate* で表現される (サブ) インタプリタを
   抹消します。 *tstate* は現在のスレッド状態でなければなりません。下
   記のスレッド状態に関する議論を参照してください。関数呼び出しが戻っ
   たとき、現在のスレッド状態は *NULL* になっています。このインタプリ
   タに関連付けられた全てのスレッド状態は抹消されます。 (この関数を呼
   び出す前にはGILを保持しておかなければならず、ロックは関数が戻ったと
   きも保持されています。) "Py_FinalizeEx()" は、その時点で明示的に抹
   消されていない全てのサブインタプリタを抹消します。


バグと注意事項
--------------

サブインタプリタ (とメインインタプリタ) は同じプロセスの一部分なので、
インタプリタ間の隔離は完璧ではありません --- 例えば、 "os.close()" の
ような低レベルのファイル操作を使うと、 (偶然なり故意なりに) 互いのイン
タプリタ下にある開かれたファイルに影響を及ぼせてしまいます。拡張モジュ
ールを (サブ) インタプリタ間で共有する方法のせいで、拡張モジュールによ
っては正しく動作しないかもしれません; 拡張モジュールが (静的な) グロー
バル変数を利用している場合や、拡張モジュールが初期化後に自身のモジュー
ル辞書を操作する場合には特にそうです。一つのサブインタプリタで生成され
たオブジェクトは他のサブインタプリタの名前空間への挿入が可能です; ユー
ザ定義関数、メソッド、インスタンスおよびクラスをサブインタプリタをサブ
インタプリタ間で共有しないように十分注意してください。というのは、これ
らの共有オブジェクトが実行した import 文は間違った (サブ) インタプリタ
のロード済みモジュール辞書に影響を及ぼす場合があるからです。

サブインタプリタを "PyGILState_*()" API と組み合わせるのが難しいことに
も注意してください。これらのAPIはPythonのスレッド状態とOSレベルスレッ
ドが1対1で対応していることを前提にしていて、サブインタプリタが存在する
とその前提が崩れるからです。対応する "PyGILState_Ensure()" と
"PyGILState_Release()" の呼び出しのペアの間では、サブインタプリタの切
り替えを行わないことを強く推奨します。さらに、("ctypes" のような)これ
らのAPIを使ってPythonの外で作られたスレッドから Pythonコードを実行して
いる拡張モジュールはサブインタプリタを使うと壊れる可能性があります。


非同期通知
==========

インタプリタのメインスレッドに非同期な通知を行うために提供されている仕
組みです。これらの通知は関数ポインタと void ポインタ引数という形態を取
ります。

int Py_AddPendingCall(int (*func)(void *), void *arg)

   インタプリタのメインスレッドから関数が呼び出される予定を組みます。
   成功すると "0" が返り、*func* はメインスレッドの呼び出しキューに詰
   められます。失敗すると、例外をセットせずに "-1" が返ります。

   無事にキューに詰められると、*func* は *いつかは必ず* インタプリタの
   メインスレッドから、*arg* を引数として呼び出されます。この関数は、
   通常の実行中の Python コードに対して非同期に呼び出されますが、次の
   両方の条件に合致したときに呼び出されます:

   * *bytecode* 境界上にいるとき、

   * メインスレッドが *global interpreter lock* を保持している (すな
     わ ち *func* が全ての C API を呼び出せる) とき。

   成功したら *func* は "0" を返さねばならず、失敗したら "-1" を返し例
   外をセットしなければいけません。*func* は、他の非同期通知を行うため
   に、さらに割り込まれることはありませんが、グローバルインタプリタロ
   ックが解放された場合は、スレッドの切り替えによって割り込まれる可能
   性が残っています。

   この関数は実行するのに現在のスレッド状態を必要とせず、グローバルイ
   ンタプリタロックも必要としません。

   警告: これは、非常に特別な場合にのみ役立つ、低レベルな関数です。
     *func* が可能な限り早く呼び出される保証はありません。メインスレッ
     ドがシ ステムコールを実行するのに忙しい場合は、 *func* はシステム
     コール が返ってくるまで呼び出されないでしょう。この関数は一般的に
     は、任 意の C スレッドから Python コードを呼び出すのには **向きま
     せん** 。これの代わりに、 PyGILState API を使用してください。

   バージョン 3.1 で追加.


プロファイルとトレース (profiling and tracing)
==============================================

Python インタプリタは、プロファイル: 分析 (profile) や実行のトレース:
追跡 (trace) といった機能を組み込むために低水準のサポートを提供してい
ます。このサポートは、プロファイルやデバッグ、適用範囲分析 (coverage
analysis) ツールなどに使われます。

この C インタフェースは、プロファイルやトレース作業時に、Python レベル
の呼び出し可能オブジェクトが呼び出されることによるオーバヘッドを避け、
直接 C 関数呼び出しが行えるようにしています。プロファイルやトレース機
能の本質的な特性は変わっていません; インタフェースではトレース関数をス
レッドごとにインストールでき、トレース関数に報告される基本イベント
(basic event) は以前のバージョンにおいて Python レベルのトレース関数で
報告されていたものと同じです。

int (*Py_tracefunc)(PyObject *obj, PyFrameObject *frame, int what, PyObject *arg)

   "PyEval_SetProfile()" および "PyEval_SetTrace()" を使って登録できる
   トレース関数の形式です。最初のパラメタはオブジェクトで、登録関数に
   *obj* として渡されます。 *frame* はイベントが属している実行フレーム
   オブジェクトで、 *what* は定数 "PyTrace_CALL", "PyTrace_EXCEPTION",
   "PyTrace_LINE", "PyTrace_RETURN", "PyTrace_C_CALL",
   "PyTrace_C_EXCEPTION", あるいは "PyTrace_C_RETURN" のいずれかで、
   *arg* は *what* の値によって以下のように異なります:

   +--------------------------------+----------------------------------------+
   | *what* の値                    | *arg* の意味                           |
   |================================|========================================|
   | "PyTrace_CALL"                 | 常に "Py_None" 。                      |
   +--------------------------------+----------------------------------------+
   | "PyTrace_EXCEPTION"            | "sys.exc_info()" の返す例外情報です。  |
   +--------------------------------+----------------------------------------+
   | "PyTrace_LINE"                 | 常に "Py_None" 。                      |
   +--------------------------------+----------------------------------------+
   | "PyTrace_RETURN"               | 呼び出し側に返される予定の値か、例外に |
   |                                | よって関数を抜ける場合は *NULL* です。 |
   +--------------------------------+----------------------------------------+
   | "PyTrace_C_CALL"               | 呼び出される関数オブジェクト。         |
   +--------------------------------+----------------------------------------+
   | "PyTrace_C_EXCEPTION"          | 呼び出される関数オブジェクト。         |
   +--------------------------------+----------------------------------------+
   | "PyTrace_C_RETURN"             | 呼び出される関数オブジェクト。         |
   +--------------------------------+----------------------------------------+

int PyTrace_CALL

   関数やメソッドが新たに呼び出されたり、ジェネレータが新たなエントリ
   の処理に入ったことを報告する際の、 "Py_tracefunc" の *what* の値で
   す。イテレータやジェネレータ関数の生成は、対応するフレーム内の
   Python バイトコードに制御の委譲 (control transfer) が起こらないため
   報告されないので注意してください。

int PyTrace_EXCEPTION

   例外が送出された際の "Py_tracefunc" の *what* の値です。現在実行さ
   れているフレームで例外がセットされ、何らかのバイトコードが処理され
   た後に、 *what* にこの値がセットされた状態でコールバック関数が呼び
   出されます。この結果、例外の伝播によって Python が呼び出しスタック
   を逆戻りする際に、各フレームから処理が戻るごとにコールバック関数が
   呼び出されます。トレース関数だけがこれらのイベントを受け取ります;
   プロファイラはこの種のイベントを必要としません。

int PyTrace_LINE

   行番号イベントを報告するときに (プロファイル関数ではなく) トレース
   関数の *what* パラメタとして渡す値です。

int PyTrace_RETURN

   呼び出しが返るときに "Py_tracefunc" 関数に *what* パラメタとして渡
   す値です。

int PyTrace_C_CALL

   C関数を呼び出す直前に "Py_tracefunc" 関数の *what* パラメタとして渡
   す値です。

int PyTrace_C_EXCEPTION

   C関数が例外を送出したときに "Py_tracefunc" 関数の *what* パラメタと
   して渡す値です。

int PyTrace_C_RETURN

   C関数から戻るときに "Py_tracefunc" 関数の *what* パラメタとして渡す
   値です。

void PyEval_SetProfile(Py_tracefunc func, PyObject *obj)

   Set the profiler function to *func*.  The *obj* parameter is passed
   to the function as its first parameter, and may be any Python
   object, or *NULL*.  If the profile function needs to maintain
   state, using a different value for *obj* for each thread provides a
   convenient and thread-safe place to store it.  The profile function
   is called for all monitored events except "PyTrace_LINE" and
   "PyTrace_EXCEPTION".

void PyEval_SetTrace(Py_tracefunc func, PyObject *obj)

   Set the tracing function to *func*.  This is similar to
   "PyEval_SetProfile()", except the tracing function does receive
   line-number events and does not receive any event related to C
   function objects being called. Any trace function registered using
   "PyEval_SetTrace()" will not receive "PyTrace_C_CALL",
   "PyTrace_C_EXCEPTION" or "PyTrace_C_RETURN" as a value for the
   *what* parameter.

PyObject* PyEval_GetCallStats(PyObject *self)

   Return a tuple of function call counts.  There are constants
   defined for the positions within the tuple:

   +---------------------------------+---------+
   | 名前                            | 値      |
   |=================================|=========|
   | "PCALL_ALL"                     | 0       |
   +---------------------------------+---------+
   | "PCALL_FUNCTION"                | 1       |
   +---------------------------------+---------+
   | "PCALL_FAST_FUNCTION"           | 2       |
   +---------------------------------+---------+
   | "PCALL_FASTER_FUNCTION"         | 3       |
   +---------------------------------+---------+
   | "PCALL_METHOD"                  | 4       |
   +---------------------------------+---------+
   | "PCALL_BOUND_METHOD"            | 5       |
   +---------------------------------+---------+
   | "PCALL_CFUNCTION"               | 6       |
   +---------------------------------+---------+
   | "PCALL_TYPE"                    | 7       |
   +---------------------------------+---------+
   | "PCALL_GENERATOR"               | 8       |
   +---------------------------------+---------+
   | "PCALL_OTHER"                   | 9       |
   +---------------------------------+---------+
   | "PCALL_POP"                     | 10      |
   +---------------------------------+---------+

   "PCALL_FAST_FUNCTION" means no argument tuple needs to be created.
   "PCALL_FASTER_FUNCTION" means that the fast-path frame setup code
   is used.

   If there is a method call where the call can be optimized by
   changing the argument tuple and calling the function directly, it
   gets recorded twice.

   This function is only present if Python is compiled with
   "CALL_PROFILE" defined.


高度なデバッガサポート (advanced debugger support)
==================================================

以下の関数は高度なデバッグツールでの使用のためだけのものです。

PyInterpreterState* PyInterpreterState_Head()

   インタプリタ状態オブジェクトからなるリストのうち、先頭にあるものを
   返します。

PyInterpreterState* PyInterpreterState_Next(PyInterpreterState *interp)

   インタプリタ状態オブジェクトからなるリストのうち、*interp* の次にあ
   るものを返します。

PyThreadState * PyInterpreterState_ThreadHead(PyInterpreterState *interp)

   インタプリタ *interp* に関連付けられているスレッドからなるリストの
   うち、先頭にある "PyThreadState" オブジェクトを返します。

PyThreadState* PyThreadState_Next(PyThreadState *tstate)

   *tstate* と同じ "PyInterpreterState" オブジェクトに属しているスレッ
   ド状態オブジェクトのうち、 *tstate* の次にあるものを返します。
