intro.po

# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2001-2020, Python Software Foundation
# This file is distributed under the same license as the Python package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
# 
# Translators:
# 秘湯 <xwhhsprings@gmail.com>, 2017
# Arihiro TAKASE, 2017
# Osamu NAKAMURA, 2017
# Inada Naoki <songofacandy@gmail.com>, 2017
# tomo, 2020
# 
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Python 3.8\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2020-04-27 13:43+0000\n"
"PO-Revision-Date: 2017-02-16 17:36+0000\n"
"Last-Translator: tomo, 2020\n"
"Language-Team: Japanese (https://www.transifex.com/python-doc/teams/5390/ja/)\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Language: ja\n"
"Plural-Forms: nplurals=1; plural=0;\n"

#: ../../c-api/intro.rst:8
msgid "Introduction"
msgstr "はじめに"

#: ../../c-api/intro.rst:10
msgid ""
"The Application Programmer's Interface to Python gives C and C++ programmers"
" access to the Python interpreter at a variety of levels.  The API is "
"equally usable from C++, but for brevity it is generally referred to as the "
"Python/C API.  There are two fundamentally different reasons for using the "
"Python/C API. The first reason is to write *extension modules* for specific "
"purposes; these are C modules that extend the Python interpreter.  This is "
"probably the most common use.  The second reason is to use Python as a "
"component in a larger application; this technique is generally referred to "
"as :dfn:`embedding` Python in an application."
msgstr ""
"Python のアプリケーションプログラマ用インタフェース (Application Programmer's Interface, API) は、 "
"Python インタプリタに対する様々なレベルでのアクセス手段を C や C++ のプログラマに提供しています。この API は通常 C++ "
"からも全く同じように利用できるのですが、簡潔な呼び名にするために Python/C API と名づけられています。根本的に異なる二つの目的から、 "
"Python/C API が用いられます。第一は、特定用途の *拡張モジュール (extention module)* 、すなわち Python "
"インタプリタを拡張する C で書かれたモジュールを記述する、という目的です。第二は、より大規模なアプリケーション内で Python を構成要素 "
"(component) として利用するという目的です; このテクニックは、一般的にはアプリケーションへの Python の埋め込み "
"(:dfn:`embedding`) と呼びます。"

#: ../../c-api/intro.rst:20
msgid ""
"Writing an extension module is a relatively well-understood process, where a"
" \"cookbook\" approach works well.  There are several tools that automate "
"the process to some extent.  While people have embedded Python in other "
"applications since its early existence, the process of embedding Python is "
"less straightforward than writing an extension."
msgstr ""
"拡張モジュールの作成は比較的わかりやすいプロセスで、 \"手引書 (cookbook)\" "
"的なアプローチでうまく実現できます。作業をある程度まで自動化してくれるツールもいくつかあります。一方、他のアプリケーションへの Python "
"の埋め込みは、Python ができてから早い時期から行われてきましたが、拡張モジュールの作成に比べるとやや難解です。"

#: ../../c-api/intro.rst:26
msgid ""
"Many API functions are useful independent of whether you're embedding  or "
"extending Python; moreover, most applications that embed Python  will need "
"to provide a custom extension as well, so it's probably a  good idea to "
"become familiar with writing an extension before  attempting to embed Python"
" in a real application."
msgstr ""
"多くの API 関数は、Python の埋め込みであるか拡張であるかに関わらず役立ちます; とはいえ、Python "
"を埋め込んでいるほとんどのアプリケーションは、同時に自作の拡張モジュールも提供する必要が生じることになるでしょうから、Python "
"を実際にアプリケーションに埋め込んでみる前に拡張モジュールの書き方に詳しくなっておくのはよい考えだと思います。"

#: ../../c-api/intro.rst:34
msgid "Coding standards"
msgstr "コーディング基準"

#: ../../c-api/intro.rst:36
msgid ""
"If you're writing C code for inclusion in CPython, you **must** follow the "
"guidelines and standards defined in :PEP:`7`.  These guidelines apply "
"regardless of the version of Python you are contributing to.  Following "
"these conventions is not necessary for your own third party extension "
"modules, unless you eventually expect to contribute them to Python."
msgstr ""
"CPython に含める C コードを書いている場合は、 :PEP:`7` のガイドラインと基準に従わなければ **なりません** 。\n"
"このガイドラインは、コントリビュート対象の Python のバージョンに関係無く適用されます。\n"
"自身のサードパーティーのモジュールでは、それをいつか Python にコントリビュートするつもりでなければ、この慣習に従う必要はありません。"

#: ../../c-api/intro.rst:46
msgid "Include Files"
msgstr "インクルードファイル"

#: ../../c-api/intro.rst:48
msgid ""
"All function, type and macro definitions needed to use the Python/C API are "
"included in your code by the following line::"
msgstr "Python/C API を使うために必要な、関数、型およびマクロの全ての定義をインクルードするには、以下の行::"

#: ../../c-api/intro.rst:54
msgid ""
"This implies inclusion of the following standard headers: ``<stdio.h>``, "
"``<string.h>``, ``<errno.h>``, ``<limits.h>``, ``<assert.h>`` and "
"``<stdlib.h>`` (if available)."
msgstr ""
"をソースコードに記述します。この行を記述すると、標準ヘッダ: ``<stdio.h>``, ``<string.h>``, ``<errno.h>``,"
" ``<limits.h>``, ``<assert.h>``, ``<stdlib.h>`` を (利用できれば) インクルードします。"

#: ../../c-api/intro.rst:60
msgid ""
"Since Python may define some pre-processor definitions which affect the "
"standard headers on some systems, you *must* include :file:`Python.h` before"
" any standard headers are included."
msgstr ""
"Python は、システムによっては標準ヘッダの定義に影響するようなプリプロセッサ定義を行っているので、 :file:`Python.h` "
"をいずれの標準ヘッダよりも前にインクルード *せねばなりません* 。"

#: ../../c-api/intro.rst:64
msgid ""
"It is recommended to always define ``PY_SSIZE_T_CLEAN`` before including "
"``Python.h``.  See :ref:`arg-parsing` for a description of this macro."
msgstr ""
"``Python.h`` をインクルードする前に、常に ``PY_SSIZE_T_CLEAN`` を定義することが推奨されます。\n"
"このマクロの解説については :ref:`arg-parsing` を参照してください。"

#: ../../c-api/intro.rst:67
msgid ""
"All user visible names defined by Python.h (except those defined by the "
"included standard headers) have one of the prefixes ``Py`` or ``_Py``.  "
"Names beginning with ``_Py`` are for internal use by the Python "
"implementation and should not be used by extension writers. Structure member"
" names do not have a reserved prefix."
msgstr ""
"Python.h で定義されている、ユーザから見える名前全て (Python.h がインクルードしている標準ヘッダの名前は除きます) には、接頭文字列 "
"``Py`` または ``_Py`` が付きます。``_Py`` で始まる名前は Python "
"実装で内部使用するための名前で、拡張モジュールの作者は使ってはなりません。構造体のメンバには予約済みの接頭文字列はありません。"

#: ../../c-api/intro.rst:74
msgid ""
"User code should never define names that begin with ``Py`` or ``_Py``. This "
"confuses the reader, and jeopardizes the portability of the user code to "
"future Python versions, which may define additional names beginning with one"
" of these prefixes."
msgstr ""
"API のユーザは、``Py`` や ``_Py`` で始まる名前を定義するコードを絶対に書いてはなりません。\n"
"後からコードを読む人を混乱させたり、将来の Python のバージョンで同じ名前が定義されて、ユーザの書いたコードの可搬性を危うくする可能性があります。"

#: ../../c-api/intro.rst:79
msgid ""
"The header files are typically installed with Python.  On Unix, these  are "
"located in the directories :file:`{prefix}/include/pythonversion/` and "
":file:`{exec_prefix}/include/pythonversion/`, where :envvar:`prefix` and "
":envvar:`exec_prefix` are defined by the corresponding parameters to "
"Python's :program:`configure` script and *version* is ``'%d.%d' % "
"sys.version_info[:2]``.  On Windows, the headers are installed in "
":file:`{prefix}/include`, where :envvar:`prefix` is the installation "
"directory specified to the installer."
msgstr ""
"ヘッダファイル群は通常 Python と共にインストールされます。 Unixでは "
":file:`{prefix}/include/pythonversion/` および "
":file:`{exec_prefix}/include/pythonversion/` に置かれます。 :envvar:`prefix` と "
":envvar:`exec_prefix` は Python をビルドする際の :program:`configure` "
"スクリプトに与えたパラメタに対応し、 *version* は ``'%d.%d' % sys.version_info[:2]`` に対応します。 "
"Windows では、ヘッダは :file:`{prefix}/include` に置かれます。 :envvar:`prefix` "
"はインストーラに指定したインストールディレクトリです。"

#: ../../c-api/intro.rst:88
msgid ""
"To include the headers, place both directories (if different) on your "
"compiler's search path for includes.  Do *not* place the parent directories "
"on the search path and then use ``#include <pythonX.Y/Python.h>``; this will"
" break on multi-platform builds since the platform independent headers under"
" :envvar:`prefix` include the platform specific headers from "
":envvar:`exec_prefix`."
msgstr ""
"ヘッダをインクルードするには、各ヘッダの入ったディレクトリ (別々のディレクトリの場合は両方) "
"を、コンパイラがインクルードファイルを検索するためのパスに入れます。親ディレクトリをサーチパスに入れて、 ``#include "
"<pythonX.Y/Python.h>`` のようにしては *なりません* ; :envvar:`prefix` "
"内のプラットフォームに依存しないヘッダは、 :envvar:`exec_prefix` "
"からプラットフォーム依存のヘッダをインクルードしているので、このような操作を行うと複数のプラットフォームでのビルドができなくなります。"

#: ../../c-api/intro.rst:95
msgid ""
"C++ users should note that although the API is defined entirely using C, the"
" header files properly declare the entry points to be ``extern \"C\"``. As a"
" result, there is no need to do anything special to use the API from C++."
msgstr ""

#: ../../c-api/intro.rst:101
msgid "Useful macros"
msgstr "便利なマクロ"

#: ../../c-api/intro.rst:103
msgid ""
"Several useful macros are defined in the Python header files.  Many are "
"defined closer to where they are useful (e.g. :c:macro:`Py_RETURN_NONE`). "
"Others of a more general utility are defined here.  This is not necessarily "
"a complete listing."
msgstr ""
"Python のヘッダーファイルには便利なマクロがいくつか定義されています。\n"
"多くのマクロは、それが役に立つところ (例えば、 :c:macro:`Py_RETURN_NONE`) の近くに定義があります。\n"
"より一般的な使われかたをする他のマクロはこれらのヘッダーファイルに定義されています。\n"
"ただし、ここで完全に列挙されているとは限りません。"

#: ../../c-api/intro.rst:110
msgid ""
"Use this when you have a code path that you do not expect to be reached. For"
" example, in the ``default:`` clause in a ``switch`` statement for which all"
" possible values are covered in ``case`` statements.  Use this in places "
"where you might be tempted to put an ``assert(0)`` or ``abort()`` call."
msgstr ""
"到達するはずがないと考えているコードパスがあるときに使います。\n"
"例えば、 ``case`` 節が全ての起こり得る値をカバーしている ``switch`` 文の ``default:`` 節です。\n"
"``assert(0)`` や ``abort()`` の呼び出しを置きたくなる場所で使ってください。"

#: ../../c-api/intro.rst:119
msgid "Return the absolute value of ``x``."
msgstr "``x`` の絶対値を返します。"

#: ../../c-api/intro.rst:125
msgid "Return the minimum value between ``x`` and ``y``."
msgstr "``x`` と ``y`` の最小値を返します。"

#: ../../c-api/intro.rst:131
msgid "Return the maximum value between ``x`` and ``y``."
msgstr "``x`` と ``y`` の最大値を返します。"

#: ../../c-api/intro.rst:137
msgid ""
"Convert ``x`` to a C string.  E.g. ``Py_STRINGIFY(123)`` returns "
"``\"123\"``."
msgstr ""
"``x`` を C 文字列へ変換します。\n"
"例えば、 ``Py_STRINGIFY(123)`` は ``\"123\"`` を返します。"

#: ../../c-api/intro.rst:144
msgid "Return the size of a structure (``type``) ``member`` in bytes."
msgstr "(``type``) 構造体の ``member`` のサイズをバイト単位で返します。"

#: ../../c-api/intro.rst:150
msgid ""
"Argument must be a character or an integer in the range [-128, 127] or [0, "
"255].  This macro returns ``c`` cast to an ``unsigned char``."
msgstr ""
"引数は文字か、[-128, 127] あるいは [0, 255] の範囲の整数でなければなりません。\n"
"このマクロは ``符号なし文字`` にキャストした ``c`` を返します。"

#: ../../c-api/intro.rst:155
msgid ""
"Like ``getenv(s)``, but returns ``NULL`` if :option:`-E` was passed on the "
"command line (i.e. if ``Py_IgnoreEnvironmentFlag`` is set)."
msgstr ""
"``getenv(s)`` に似ていますが、コマンドラインで :option:`-E` が渡された場合 (つまり "
"``Py_IgnoreEnvironmentFlag`` が設定された場合) ``NULL`` を返します。"

#: ../../c-api/intro.rst:160
msgid ""
"Use this for unused arguments in a function definition to silence compiler "
"warnings. Example: ``int func(int a, int Py_UNUSED(b)) { return a; }``."
msgstr ""

#: ../../c-api/intro.rst:167
msgid ""
"Use this for deprecated declarations.  The macro must be placed before the "
"symbol name."
msgstr ""

#: ../../c-api/intro.rst:170 ../../c-api/intro.rst:185
#: ../../c-api/intro.rst:203
msgid "Example::"
msgstr "以下はプログラム例です::"

#: ../../c-api/intro.rst:174
msgid "MSVC support was added."
msgstr "MSVC サポートが追加されました。"

#: ../../c-api/intro.rst:179
msgid ""
"Creates a variable with name ``name`` that can be used in docstrings. If "
"Python is built without docstrings, the value will be empty."
msgstr ""

#: ../../c-api/intro.rst:182
msgid ""
"Use :c:macro:`PyDoc_STRVAR` for docstrings to support building Python "
"without docstrings, as specified in :pep:`7`."
msgstr ""

#: ../../c-api/intro.rst:197
msgid ""
"Creates a docstring for the given input string or an empty string if "
"docstrings are disabled."
msgstr ""

#: ../../c-api/intro.rst:200
msgid ""
"Use :c:macro:`PyDoc_STR` in specifying docstrings to support building Python"
" without docstrings, as specified in :pep:`7`."
msgstr ""

#: ../../c-api/intro.rst:214
msgid "Objects, Types and Reference Counts"
msgstr "オブジェクト、型および参照カウント"

#: ../../c-api/intro.rst:218
msgid ""
"Most Python/C API functions have one or more arguments as well as a return "
"value of type :c:type:`PyObject\\*`.  This type is a pointer to an opaque "
"data type representing an arbitrary Python object.  Since all Python object "
"types are treated the same way by the Python language in most situations "
"(e.g., assignments, scope rules, and argument passing), it is only fitting "
"that they should be represented by a single C type.  Almost all Python "
"objects live on the heap: you never declare an automatic or static variable "
"of type :c:type:`PyObject`, only pointer variables of type "
":c:type:`PyObject\\*` can  be declared.  The sole exception are the type "
"objects; since these must never be deallocated, they are typically static "
":c:type:`PyTypeObject` objects."
msgstr ""
"Python/C API 関数は、 :c:type:`PyObject\\*` 型の一つ以上の引数と戻り値を持ちます。この型は、任意の Python "
"オブジェクトを表現する不透明 (opaque) なデータ型へのポインタです。 Python 言語は、全ての Python オブジェクト型をほとんどの状況"
" (例えば代入、スコープ規則 (scope rule)、引数渡し) で同様に扱います。ほとんど全ての Python オブジェクトはヒープ (heap) "
"上に置かれます: このため、 :c:type:`PyObject` 型のオブジェクトは、自動記憶 (automatic) としても静的記憶 "
"(static) としても宣言できません。 :c:type:`PyObject\\*` "
"型のポインタ変数のみ宣言できます。唯一の例外は、型オブジェクトです; 型オブジェクトはメモリ解放 (deallocate) "
"してはならないので、通常は静的記憶の :c:type:`PyTypeObject` オブジェクトにします。"

#: ../../c-api/intro.rst:229
msgid ""
"All Python objects (even Python integers) have a :dfn:`type` and a "
":dfn:`reference count`.  An object's type determines what kind of object it "
"is (e.g., an integer, a list, or a user-defined function; there are many "
"more as explained in :ref:`types`).  For each of the well-known types there "
"is a macro to check whether an object is of that type; for instance, "
"``PyList_Check(a)`` is true if (and only if) the object pointed to by *a* is"
" a Python list."
msgstr ""
"全ての Python オブジェクトには (Python 整数型ですら) 型 (:dfn:`type`)  と参照カウント "
"(:dfn:`reference count`) があります。あるオブジェクトの型は、そのオブジェクトがどの種類のオブジェクトか "
"(例えば整数、リスト、ユーザ定義関数、など; その他多数については :ref:`types` で説明しています) "
"を決定します。よく知られている型については、各々マクロが存在して、あるオブジェクトがその型かどうか調べられます; 例えば、 "
"``PyList_Check(a)`` は、 *a* で示されたオブジェクトが Python リスト型のとき (かつそのときに限り) 真値を返します。"

#: ../../c-api/intro.rst:240
msgid "Reference Counts"
msgstr "参照カウント法"

#: ../../c-api/intro.rst:242
msgid ""
"The reference count is important because today's computers have a  finite "
"(and often severely limited) memory size; it counts how many  different "
"places there are that have a reference to an object.  Such a  place could be"
" another object, or a global (or static) C variable, or  a local variable in"
" some C function. When an object's reference count  becomes zero, the object"
" is deallocated.  If it contains references to  other objects, their "
"reference count is decremented. Those other  objects may be deallocated in "
"turn, if this decrement makes their reference count become zero, and so on."
"  (There's an obvious problem  with objects that reference each other here; "
"for now, the solution is  \"don't do that.\")"
msgstr ""
"今日の計算機は有限の (しばしば非常に限られた) メモリサイズしか持たないので、参照カウントは重要な概念です; "
"参照カウントは、あるオブジェクトに対して参照を行っている場所が何箇所あるかを数える値です。参照を行っている場所とは、別のオブジェクトであったり、グローバルな"
" (あるいは静的な) C 変数であったり、何らかの C "
"関数内にあるローカルな変数だったりします。あるオブジェクトの参照カウントがゼロになると、そのオブジェクトは解放されます。そのオブジェクトに他のオブジェクトへの参照が入っていれば、他のオブジェクトの参照カウントはデクリメントされます。デクリメントの結果、他のオブジェクトの参照カウントがゼロになると、今度はそのオブジェクトが解放される、といった具合に以後続きます。(言うまでもなく、互いを参照しあうオブジェクトについて問題があります;"
" 現状では、解決策は \"何もしない\" です。)"

#: ../../c-api/intro.rst:257
msgid ""
"Reference counts are always manipulated explicitly.  The normal way is  to "
"use the macro :c:func:`Py_INCREF` to increment an object's reference count "
"by one, and :c:func:`Py_DECREF` to decrement it by   one.  The "
":c:func:`Py_DECREF` macro is considerably more complex than the incref one, "
"since it must check whether the reference count becomes zero and then cause "
"the object's deallocator to be called. The deallocator is a function pointer"
" contained in the object's type structure.  The type-specific deallocator "
"takes care of decrementing the reference counts for other objects contained "
"in the object if this is a compound object type, such as a list, as well as "
"performing any additional finalization that's needed.  There's no chance "
"that the reference count can overflow; at least as many bits are used to "
"hold the reference count as there are distinct memory locations in virtual "
"memory (assuming ``sizeof(Py_ssize_t) >= sizeof(void*)``). Thus, the "
"reference count increment is a simple operation."
msgstr ""
"参照カウントは、常に明示的なやり方で操作されます。通常の方法では、 :c:func:`Py_INCREF` マクロでオブジェクトの参照を 1 "
"インクリメントし、 :c:func:`Py_DECREF` マクロで 1 デクリメントします。 :c:func:`Py_DECREF` "
"マクロは、incref よりもかなり複雑です。というのは、 Py_DECREF "
"マクロは参照カウントがゼロになったかどうかを調べて、なった場合にはオブジェクトのメモリ解放関数 (deallocator) "
"を呼び出さなければならないからです。メモリ解放関数とは、オブジェクトの型を定義している構造体内にある関数へのポインタです。型固有のメモリ解放関数は、その型が複合オブジェクト"
" (compound object) "
"型である場合には、オブジェクト内の他のオブジェクトに対する参照カウントをデクリメントするよう気を配るとともに、その他の必要なファイナライズ "
"(finalize) 処理を実行します。参照カウントがオーバフローすることはありません; "
"というのも、仮想メモリ空間には、(``sizeof(Py_ssize_t) >= sizeof(void*)`` と仮定した場合) "
"少なくとも参照カウントの記憶に使われるビット数と同じだけのメモリ上の位置があるからです。従って、参照カウントのインクリメントは単純な操作になります。"

#: ../../c-api/intro.rst:271
msgid ""
"It is not necessary to increment an object's reference count for every  "
"local variable that contains a pointer to an object.  In theory, the  "
"object's reference count goes up by one when the variable is made to  point "
"to it and it goes down by one when the variable goes out of  scope.  "
"However, these two cancel each other out, so at the end the  reference count"
" hasn't changed.  The only real reason to use the  reference count is to "
"prevent the object from being deallocated as  long as our variable is "
"pointing to it.  If we know that there is at  least one other reference to "
"the object that lives at least as long as our variable, there is no need to "
"increment the reference count  temporarily. An important situation where "
"this arises is in objects  that are passed as arguments to C functions in an"
" extension module  that are called from Python; the call mechanism "
"guarantees to hold a  reference to every argument for the duration of the "
"call."
msgstr ""
"オブジェクトへのポインタが入っているローカルな変数全てについて、オブジェクトの参照カウントを必ずインクリメントしなければならないわけではありません。理論上は、オブジェクトの参照カウントは、オブジェクトを指し示す変数が生成されたときに"
" 1 増やされ、その変数がスコープから出て行った際に 1 "
"減らされます。しかしこの場合、二つの操作は互いに相殺するので、結果的に参照カウントは変化しません。参照カウントを使う真の意義とは、手持ちの何らかの変数がオブジェクトを指している間はオブジェクトがデアロケートされないようにすることにあります。オブジェクトに対して、一つでも別の参照が行われていて、その参照が手持ちの変数と同じ間維持されるのなら、参照カウントを一時的に増やす必要はありません。参照カウント操作の必要性が浮き彫りになる重要な局面とは、Python"
" から呼び出された拡張モジュール内の C 関数にオブジェクトを引数として渡すときです; "
"呼び出しメカニズムは、呼び出しの間全ての引数に対する参照を保証します。"

#: ../../c-api/intro.rst:285
msgid ""
"However, a common pitfall is to extract an object from a list and hold on to"
" it for a while without incrementing its reference count. Some other "
"operation might conceivably remove the object from the list, decrementing "
"its reference count and possibly deallocating it. The real danger is that "
"innocent-looking operations may invoke arbitrary Python code which could do "
"this; there is a code path which allows control to flow back to the user "
"from a :c:func:`Py_DECREF`, so almost any operation is potentially "
"dangerous."
msgstr ""
"しかしながら、よく陥る過ちとして、あるオブジェクトをリストから得たときに、参照カウントをインクリメントせずにしばらく放っておくというのがあります。他の操作がオブジェクトをリストから除去してしまい、参照カウントがデクリメントされてデアロケートされてしまうことが考えられます。本当に危険なのは、まったく無害そうにみえる操作が、上記の動作を引き起こす何らかの"
" Python コードを呼び出しかねないということです; :c:func:`Py_DECREF` "
"からユーザへ制御を戻せるようなコードパスが存在するため、ほとんど全ての操作が潜在的に危険をはらむことになります。"

#: ../../c-api/intro.rst:293
msgid ""
"A safe approach is to always use the generic operations (functions  whose "
"name begins with ``PyObject_``, ``PyNumber_``, ``PySequence_`` or "
"``PyMapping_``). These operations always increment the reference count of "
"the object they return. This leaves the caller with the responsibility to "
"call :c:func:`Py_DECREF` when they are done with the result; this soon "
"becomes second nature."
msgstr ""
"安全に参照カウントを操作するアプローチは、汎用の操作 (関数名が  ``PyObject_``, ``PyNumber_``, "
"``PySequence_``, および  ``PyMapping_`` で始まる関数) "
"の利用です。これらの操作は常に戻り値となるオブジェクトの参照カウントをインクリメントします。ユーザには戻り値が不要になったら "
":c:func:`Py_DECREF` を呼ぶ責任が残されています; とはいえ、すぐにその習慣は身に付くでしょう。"

#: ../../c-api/intro.rst:303
msgid "Reference Count Details"
msgstr "参照カウントの詳細"

#: ../../c-api/intro.rst:305
msgid ""
"The reference count behavior of functions in the Python/C API is best  "
"explained in terms of *ownership of references*.  Ownership pertains to "
"references, never to objects (objects are not owned: they are always "
"shared).  \"Owning a reference\" means being responsible for calling "
"Py_DECREF on it when the reference is no longer needed.  Ownership can also "
"be transferred, meaning that the code that receives ownership of the "
"reference then becomes responsible for eventually decref'ing it by calling "
":c:func:`Py_DECREF` or :c:func:`Py_XDECREF` when it's no longer needed---or "
"passing on this responsibility (usually to its caller). When a function "
"passes ownership of a reference on to its caller, the caller is said to "
"receive a *new* reference.  When no ownership is transferred, the caller is "
"said to *borrow* the reference. Nothing needs to be done for a borrowed "
"reference."
msgstr ""
"Python/C API の各関数における参照カウントの振る舞いは、説明するには、 *参照の所有権 (ownership of references)*"
" という言葉でうまく説明できます。所有権は参照に対するもので、オブジェクトに対するものではありません "
"(オブジェクトは誰にも所有されず、常に共有されています)。ある \"参照の所有\" は、その参照が必要なくなった時点で Py_DECREF "
"を呼び出す役割を担うことを意味します。所有権は委譲でき、あるコードが委譲によって所有権を得ると、今度はそのコードが参照が必要なくなった際に最終的に "
":c:func:`Py_DECREF` や :c:func:`Py_XDECREF` を呼び出して、参照カウンタを1つ減らす役割を担います --- "
"あるいは、その役割を (通常はコードを呼び出した元に) 受け渡します。ある関数が、関数の呼び出し側に対して参照の所有権を渡すと、呼び出し側は *新たな*"
" 参照 (new reference) を得る、と言います。所有権が渡されない場合、呼び出し側は参照を *借りる* (borrow) "
"といいます。借りた参照に対しては、何もする必要はありません。"

#: ../../c-api/intro.rst:318
msgid ""
"Conversely, when a calling function passes in a reference to an  object, "
"there are two possibilities: the function *steals* a  reference to the "
"object, or it does not.  *Stealing a reference* means that when you pass a "
"reference to a function, that function assumes that it now owns that "
"reference, and you are not responsible for it any longer."
msgstr ""
"逆に、ある関数呼び出しで、あるオブジェクトへの参照を呼び出される関数に渡す際には、二つの可能性: 関数がオブジェクトへの参照を *盗み取る* "
"(steal) 場合と、そうでない場合があります。*参照を盗む* "
"とは、関数に参照を渡したときに、参照の所有者がその関数になったと仮定し、関数の呼び出し元には所有権がなくなるということです。"

#: ../../c-api/intro.rst:328
msgid ""
"Few functions steal references; the two notable exceptions are "
":c:func:`PyList_SetItem` and :c:func:`PyTuple_SetItem`, which  steal a "
"reference to the item (but not to the tuple or list into which the item is "
"put!).  These functions were designed to steal a reference because of a "
"common idiom for populating a tuple or list with newly created objects; for "
"example, the code to create the tuple ``(1, 2, \"three\")`` could look like "
"this (forgetting about error handling for the moment; a better way to code "
"this is shown below)::"
msgstr ""
"参照を盗み取る関数はほとんどありません; 例外としてよく知られているのは、 :c:func:`PyList_SetItem` と "
":c:func:`PyTuple_SetItem` で、これらはシーケンスに入れる要素に対する参照を盗み取ります "
"(しかし、要素の入る先のタプルやリストの参照は盗み取りません!)。これらの関数は、リストやタプルの中に新たに作成されたオブジェクトを入れていく際の常套的な書き方をしやすくするために、参照を盗み取るように設計されています;"
" 例えば、 ``(1, 2, \"three\")`` というタプルを生成するコードは以下のようになります (とりあえず例外処理のことは忘れておきます;"
" もっとよい書き方を後で示します)::"

#: ../../c-api/intro.rst:343
msgid ""
"Here, :c:func:`PyLong_FromLong` returns a new reference which is immediately"
" stolen by :c:func:`PyTuple_SetItem`.  When you want to keep using an object"
" although the reference to it will be stolen, use :c:func:`Py_INCREF` to "
"grab another reference before calling the reference-stealing function."
msgstr ""
"ここで、 :c:func:`PyLong_FromLong` は新しい参照を返し、すぐに :c:func:`PyTuple_SetItem` "
"に盗まれます。参照が盗まれた後もそのオブジェクトを利用したい場合は、参照盗む関数を呼び出す前に、 :c:func:`Py_INCREF` "
"を利用してもう一つの参照を取得してください。"

#: ../../c-api/intro.rst:348
msgid ""
"Incidentally, :c:func:`PyTuple_SetItem` is the *only* way to set tuple "
"items; :c:func:`PySequence_SetItem` and :c:func:`PyObject_SetItem` refuse to"
" do this since tuples are an immutable data type.  You should only use "
":c:func:`PyTuple_SetItem` for tuples that you are creating yourself."
msgstr ""
"ちなみに、 :c:func:`PyTuple_SetItem` はタプルに値をセットするための *唯一の* 方法です; "
"タプルは変更不能なデータ型なので、 :c:func:`PySequence_SetItem` や :c:func:`PyObject_SetItem` "
"を使うと上の操作は拒否されてしまいます。自分でタプルの値を入れていくつもりなら、 :c:func:`PyTuple_SetItem` "
"だけしか使えません。"

#: ../../c-api/intro.rst:353
msgid ""
"Equivalent code for populating a list can be written using "
":c:func:`PyList_New` and :c:func:`PyList_SetItem`."
msgstr ""
"同じく、リストに値を入れていくコードは :c:func:`PyList_New` と :c:func:`PyList_SetItem` で書けます。"

#: ../../c-api/intro.rst:356
msgid ""
"However, in practice, you will rarely use these ways of creating and "
"populating a tuple or list.  There's a generic function, "
":c:func:`Py_BuildValue`, that can create most common objects from C values, "
"directed by a :dfn:`format string`. For example, the above two blocks of "
"code could be replaced by the following (which also takes care of the error "
"checking)::"
msgstr ""
"しかし実際には、タプルやリストを生成して値を入れる際には、上記のような方法はほとんど使いません。より汎用性のある関数、 "
":c:func:`Py_BuildValue` があり、ほとんどの主要なオブジェクトをフォーマット文字列 :dfn:`format string` "
"の指定に基づいて C の値から生成できます。例えば、上の二種類のコードブロックは、以下のように置き換えられます (エラーチェックにも配慮しています)::"

#: ../../c-api/intro.rst:367
msgid ""
"It is much more common to use :c:func:`PyObject_SetItem` and friends with "
"items whose references you are only borrowing, like arguments that were "
"passed in to the function you are writing.  In that case, their behaviour "
"regarding reference counts is much saner, since you don't have to increment "
"a reference count so you can give a reference away (\"have it be stolen\")."
"  For example, this function sets all items of a list (actually, any mutable"
" sequence) to a given item::"
msgstr ""
"自作の関数に渡す引数のように、単に参照を借りるだけの要素に対しては、 :c:func:`PyObject_SetItem` "
"とその仲間を使うのがはるかに一般的です。その場合、参照カウントをインクリメントする必要がなく、参照を引き渡せる (\"参照を盗み取らせられる\") "
"ので、参照カウントに関する動作はより健全になります。例えば、以下の関数は与えられた要素をリスト中の全ての要素の値にセットします::"

#: ../../c-api/intro.rst:397
msgid ""
"The situation is slightly different for function return values.   While "
"passing a reference to most functions does not change your  ownership "
"responsibilities for that reference, many functions that  return a reference"
" to an object give you ownership of the reference. The reason is simple: in "
"many cases, the returned object is created  on the fly, and the reference "
"you get is the only reference to the  object.  Therefore, the generic "
"functions that return object references, like :c:func:`PyObject_GetItem` and"
"  :c:func:`PySequence_GetItem`, always return a new reference (the caller "
"becomes the owner of the reference)."
msgstr ""
"関数の戻り値の場合には、状況は少し異なります。ほとんどの関数については、参照を渡してもその参照に対する所有権が変わることがない一方で、あるオブジェクトに対する参照を返すような多くの関数は、参照に対する所有権を呼び出し側に与えます。理由は簡単です:"
" 多くの場合、関数が返すオブジェクトはその場で (on the fly) "
"生成されるため、呼び出し側が得る参照は生成されたオブジェクトに対する唯一の参照になるからです。従って、 "
":c:func:`PyObject_GetItem` や :c:func:`PySequence_GetItem` "
"のように、オブジェクトに対する参照を返す汎用の関数は、常に新たな参照を返します (呼び出し側が参照の所有者になります)。"

#: ../../c-api/intro.rst:406
msgid ""
"It is important to realize that whether you own a reference returned  by a "
"function depends on which function you call only --- *the plumage* (the type"
" of the object passed as an argument to the function) *doesn't enter into "
"it!* Thus, if you  extract an item from a list using "
":c:func:`PyList_GetItem`, you don't own the reference --- but if you obtain "
"the same item from the same list using :c:func:`PySequence_GetItem` (which "
"happens to take exactly the same arguments), you do own a reference to the "
"returned object."
msgstr ""
"重要なのは、関数が返す参照の所有権を持てるかどうかは、どの関数を呼び出すかだけによる、と理解することです --- 関数呼び出し時の *お飾り* "
"(関数に引数として渡したオブジェクトの型) は *この問題には関係ありません!* 従って、 :c:func:`PyList_GetItem` "
"を使ってリスト内の要素を得た場合には、参照の所有者にはなりません --- が、同じ要素を同じリストから "
":c:func:`PySequence_GetItem` (図らずもこの関数は全く同じ引数をとります) "
"を使って取り出すと、返されたオブジェクトに対する参照を得ます。"

#: ../../c-api/intro.rst:418
msgid ""
"Here is an example of how you could write a function that computes the sum "
"of the items in a list of integers; once using  :c:func:`PyList_GetItem`, "
"and once using :c:func:`PySequence_GetItem`. ::"
msgstr ""
"以下は、整数からなるリストに対して各要素の合計を計算する関数をどのようにして書けるかを示した例です; 一つは "
":c:func:`PyList_GetItem` を使っていて、もう一つは :c:func:`PySequence_GetItem` を使っています。 "
"::"

#: ../../c-api/intro.rst:482
msgid "Types"
msgstr "型"

#: ../../c-api/intro.rst:484
msgid ""
"There are few other data types that play a significant role in  the Python/C"
" API; most are simple C types such as :c:type:`int`,  :c:type:`long`, "
":c:type:`double` and :c:type:`char\\*`.  A few structure types  are used to "
"describe static tables used to list the functions exported  by a module or "
"the data attributes of a new object type, and another is used to describe "
"the value of a complex number.  These will  be discussed together with the "
"functions that use them."
msgstr ""
"他にも Python/C API において重要な役割を持つデータ型がいくつかあります; ほとんどは :c:type:`int`, "
":c:type:`long`,  :c:type:`double`, および :c:type:`char\\*` といった、単なる C "
"のデータ型です。また、モジュールで公開している関数を列挙する際に用いられる静的なテーブルや、新しいオブジェクト型におけるデータ属性を記述したり、複素数の値を記述したりするために構造体をいくつか使っています。これらの型については、その型を使う関数とともに説明してゆきます。"

#: ../../c-api/intro.rst:496
msgid "Exceptions"
msgstr "例外"

#: ../../c-api/intro.rst:498
msgid ""
"The Python programmer only needs to deal with exceptions if specific  error "
"handling is required; unhandled exceptions are automatically  propagated to "
"the caller, then to the caller's caller, and so on, until they reach the "
"top-level interpreter, where they are reported to the  user accompanied by a"
" stack traceback."
msgstr ""
"Python プログラマは、特定のエラー処理が必要なときだけしか例外を扱う必要はありません; "
"処理しなかった例外は、処理の呼び出し側、そのまた呼び出し側、といった具合に、トップレベルのインタプリタ層まで自動的に伝播します。インタプリタ層は、スタックトレースバックと合わせて例外をユーザに報告します。"

#: ../../c-api/intro.rst:506
msgid ""
"For C programmers, however, error checking always has to be explicit.  All "
"functions in the Python/C API can raise exceptions, unless an explicit claim"
" is made otherwise in a function's documentation.  In general, when a "
"function encounters an error, it sets an exception, discards any object "
"references that it owns, and returns an error indicator.  If not documented "
"otherwise, this indicator is either ``NULL`` or ``-1``, depending on the "
"function's return type. A few functions return a Boolean true/false result, "
"with false indicating an error.  Very few functions return no explicit error"
" indicator or have an ambiguous return value, and require explicit testing "
"for errors with :c:func:`PyErr_Occurred`.  These exceptions are always "
"explicitly documented."
msgstr ""
"ところが、 C プログラマの場合、エラーチェックは常に明示的に行わねばなりません。 Python/C API "
"の全ての関数は、関数のドキュメントで明確に説明がない限り例外を発行する可能性があります。一般的な話として、ある関数が何らかのエラーに遭遇すると、関数は例外を設定して、関数内における参照の所有権を全て放棄し、エラー値"
" (error indicator) を返します。ドキュメントに書かれてない場合、このエラー値は関数の戻り値の型によって、 ``NULL`` か "
"``-1`` "
"のどちらかになります。いくつかの関数ではブール型で真/偽を返し、偽はエラーを示します。きわめて少数の関数では明確なエラー指標を返さなかったり、あいまいな戻り値を返したりするので、"
" :c:func:`PyErr_Occurred` で明示的にエラーテストを行う必要があります。これらの例外は常に明示的にドキュメント化されます。"

#: ../../c-api/intro.rst:521
msgid ""
"Exception state is maintained in per-thread storage (this is  equivalent to "
"using global storage in an unthreaded application).  A  thread can be in one"
" of two states: an exception has occurred, or not. The function "
":c:func:`PyErr_Occurred` can be used to check for this: it returns a "
"borrowed reference to the exception type object when an exception has "
"occurred, and ``NULL`` otherwise.  There are a number of functions to set "
"the exception state: :c:func:`PyErr_SetString` is the most common (though "
"not the most general) function to set the exception state, and "
":c:func:`PyErr_Clear` clears the exception state."
msgstr ""
"例外時の状態情報 (exception state)は、スレッド単位に用意された記憶領域 (per-thread storage) 内で管理されます "
"(この記憶領域は、スレッドを使わないアプリケーションではグローバルな記憶領域と同じです)。一つのスレッドは二つの状態のどちらか: "
"例外が発生したか、まだ発生していないか、をとります。関数 :c:func:`PyErr_Occurred` を使うと、この状態を調べられます: "
"この関数は例外が発生した際にはその例外型オブジェクトに対する借用参照 (borrowed reference) を返し、そうでないときには "
"``NULL`` を返します。例外状態を設定する関数は数多くあります: :c:func:`PyErr_SetString` はもっともよく知られている "
"(が、もっとも汎用性のない) 例外を設定するための関数で、 :c:func:`PyErr_Clear` は例外状態情報を消し去る関数です。"

#: ../../c-api/intro.rst:531
msgid ""
"The full exception state consists of three objects (all of which can  be "
"``NULL``): the exception type, the corresponding exception  value, and the "
"traceback.  These have the same meanings as the Python result of "
"``sys.exc_info()``; however, they are not the same: the Python objects "
"represent the last exception being handled by a Python  :keyword:`try` ... "
":keyword:`except` statement, while the C level exception state only exists "
"while an exception is being passed on between C functions until it reaches "
"the Python bytecode interpreter's  main loop, which takes care of "
"transferring it to ``sys.exc_info()`` and friends."
msgstr ""
"完全な例外状態情報は、3 つのオブジェクト: 例外の型、例外の値、そしてトレースバック、からなります  (どのオブジェクトも ``NULL`` "
"を取り得ます)。これらの情報は、 Python の ``sys.exc_info()`` の結果と同じ意味を持ちます; とはいえ、 C と Python"
" の例外状態情報は全く同じではありません: Python における例外オブジェクトは、Python の :keyword:`try` ...  "
":keyword:`except` 文で最近処理したオブジェクトを表す一方、 C レベルの例外状態情報が存続するのは、渡された例外情報を "
"``sys.exc_info()`` その他に転送するよう取り計らう Python "
"のバイトコードインタプリタのメインループに到達するまで、例外が関数の間で受け渡しされている間だけです。"

#: ../../c-api/intro.rst:543
msgid ""
"Note that starting with Python 1.5, the preferred, thread-safe way to access"
" the exception state from Python code is to call the function "
":func:`sys.exc_info`, which returns the per-thread exception state for "
"Python code.  Also, the semantics of both ways to access the exception state"
" have changed so that a function which catches an exception will save and "
"restore its thread's exception state so as to preserve the exception state "
"of its caller.  This prevents common bugs in exception handling code caused "
"by an innocent-looking function overwriting the exception being handled; it "
"also reduces the often unwanted lifetime extension for objects that are "
"referenced by the stack frames in the traceback."
msgstr ""
"Python 1.5 からは、Python で書かれたコードから例外状態情報にアクセスする方法として、推奨されていてスレッドセーフな方法は "
":func:`sys.exc_info` になっているので注意してください。この関数は Python "
"コードの実行されているスレッドにおける例外状態情報を返します。また、これらの例外状態情報に対するアクセス手段は、両方とも意味づけ (semantics)"
" "
"が変更され、ある関数が例外を捕捉すると、その関数を実行しているスレッドの例外状態情報を保存して、呼び出し側の例外状態情報を維持するようになりました。この変更によって、無害そうに見える関数が現在扱っている例外を上書きすることで引き起こされる、例外処理コードでよくおきていたバグを抑止しています;"
" また、トレースバック内のスタックフレームで参照されているオブジェクトがしばしば不必要に寿命を永らえていたのをなくしています。"

#: ../../c-api/intro.rst:554
msgid ""
"As a general principle, a function that calls another function to  perform "
"some task should check whether the called function raised an  exception, and"
" if so, pass the exception state on to its caller.  It  should discard any "
"object references that it owns, and return an  error indicator, but it "
"should *not* set another exception --- that would overwrite the exception "
"that was just raised, and lose important information about the exact cause "
"of the error."
msgstr ""
"一般的な原理として、ある関数が別の関数を呼び出して何らかの作業をさせるとき、呼び出し先の関数が例外を送出していないか調べなくてはならず、もし送出していれば、その例外状態情報は呼び出し側に渡されなければなりません。呼び出し元の関数はオブジェクト参照の所有権をすべて放棄し、エラー指標を返さなくてはなりませんが、余計に例外を設定する必要は"
" *ありません* --- "
"そんなことをすれば、たった今送出されたばかりの例外を上書きしてしまい、エラーの原因そのものに関する重要な情報を失うことになります。"

#: ../../c-api/intro.rst:563
msgid ""
"A simple example of detecting exceptions and passing them on is shown in the"
" :c:func:`sum_sequence` example above.  It so happens that this example "
"doesn't need to clean up any owned references when it detects an error.  The"
" following example function shows some error cleanup.  First, to remind you "
"why you like Python, we show the equivalent Python code::"
msgstr ""
"例外を検出して渡す例は、上の :c:func:`sum_sequence` "
"で示しています。偶然にも、この例ではエラーを検出した際に何ら参照を放棄する必要がありません。以下の関数の例では、エラーに対する後始末について示しています。まず、どうして"
" Python で書くのが好きか思い出してもらうために、等価な Python コードを示します::"

#: ../../c-api/intro.rst:578
msgid "Here is the corresponding C code, in all its glory::"
msgstr "以下は対応するコードを C で完璧に書いたものです::"

#: ../../c-api/intro.rst:630
msgid ""
"This example represents an endorsed use of the ``goto`` statement  in C! It "
"illustrates the use of :c:func:`PyErr_ExceptionMatches` and "
":c:func:`PyErr_Clear` to handle specific exceptions, and the use of "
":c:func:`Py_XDECREF` to dispose of owned references that may be ``NULL`` "
"(note the ``'X'`` in the name; :c:func:`Py_DECREF` would crash when "
"confronted with a ``NULL`` reference).  It is important that the variables "
"used to hold owned references are initialized to ``NULL`` for this to work; "
"likewise, the proposed return value is initialized to ``-1`` (failure) and "
"only set to success after the final call made is successful."
msgstr ""
"なんとこの例は C で ``goto`` 文を使うお勧めの方法まで示していますね! この例では、特定の例外を処理するために "
":c:func:`PyErr_ExceptionMatches`  および :c:func:`PyErr_Clear` "
"をどう使うかを示しています。また、所有権を持っている参照で、値が ``NULL`` になるかもしれないものを捨てるために  "
":c:func:`Py_XDECREF` をどう使うかも示しています (関数名に ``'X'`` が付いていることに注意してください; "
":c:func:`Py_DECREF` は ``NULL`` "
"参照に出くわすとクラッシュします)。正しく動作させるためには、所有権を持つ参照を保持するための変数を ``NULL`` で初期化することが重要です; "
"同様に、あらかじめ戻り値を定義する際には値を ``-1`` (失敗) で初期化しておいて、最後の関数呼び出しまでうまくいった場合にのみ ``0`` "
"(成功) に設定します。"

#: ../../c-api/intro.rst:644
msgid "Embedding Python"
msgstr "Python の埋め込み"

#: ../../c-api/intro.rst:646
msgid ""
"The one important task that only embedders (as opposed to extension writers)"
" of the Python interpreter have to worry about is the initialization, and "
"possibly the finalization, of the Python interpreter.  Most functionality of"
" the interpreter can only be used after the interpreter has been "
"initialized."
msgstr ""
"Python インタプリタの埋め込みを行う人 (いわば拡張モジュールの書き手の対極) が気にかけなければならない重要なタスクは、Python "
"インタプリタの初期化処理 (initialization)、そしておそらくは終了処理 (finalization) "
"です。インタプリタのほとんどの機能は、インタプリタの起動後しか使えません。"

#: ../../c-api/intro.rst:659
msgid ""
"The basic initialization function is :c:func:`Py_Initialize`. This "
"initializes the table of loaded modules, and creates the fundamental modules"
" :mod:`builtins`, :mod:`__main__`, and :mod:`sys`.  It also initializes the "
"module search path (``sys.path``)."
msgstr ""
"基本的な初期化処理を行う関数は :c:func:`Py_Initialize` "
"です。この関数はロード済みのモジュールからなるテーブルを作成し、土台となるモジュール :mod:`builtins`, :mod:`__main__`,"
" および :mod:`sys` を作成します。また、モジュール検索パス (``sys.path``)    の初期化も行います。"

#: ../../c-api/intro.rst:666
msgid ""
":c:func:`Py_Initialize` does not set the \"script argument list\"  "
"(``sys.argv``). If this variable is needed by Python code that will be "
"executed later, it must be set explicitly with a call to  "
"``PySys_SetArgvEx(argc, argv, updatepath)`` after the call to "
":c:func:`Py_Initialize`."
msgstr ""
":c:func:`Py_Initialize` の中では、 \"スクリプトへの引数リスト\" (script argument list, "
"``sys.argv`` のこと) を設定しません。この変数が後に実行される Python コード中で必要なら、 "
":c:func:`Py_Initialize` の後で ``PySys_SetArgvEx(argc, argv, updatepath)`` "
"を呼び出して明示的に設定しなければなりません。"

#: ../../c-api/intro.rst:671
msgid ""
"On most systems (in particular, on Unix and Windows, although the details "
"are slightly different), :c:func:`Py_Initialize` calculates the module "
"search path based upon its best guess for the location of the standard "
"Python interpreter executable, assuming that the Python library is found in "
"a fixed location relative to the Python interpreter executable.  In "
"particular, it looks for a directory named :file:`lib/python{X.Y}` relative "
"to the parent directory where the executable named :file:`python` is found "
"on the shell command search path (the environment variable :envvar:`PATH`)."
msgstr ""
"ほとんどのシステムでは (特に Unix と Windows は、詳細がわずかに異なりはしますが)、 :c:func:`Py_Initialize` "
"は標準の Python インタプリタ実行形式の場所に対する推定結果に基づいて、 Python のライブラリが Python "
"インタプリタ実行形式からの相対パスで見つかるという仮定の下にモジュール検索パスを計算します。とりわけこの検索では、シェルコマンド検索パス (環境変数 "
":envvar:`PATH`) 上に見つかった :file:`python` "
"という名前の実行ファイルの置かれているディレクトリの親ディレクトリからの相対で、 :file:`lib/python{X.Y}` "
"という名前のディレクトリを探します。"

#: ../../c-api/intro.rst:680
msgid ""
"For instance, if the Python executable is found in "
":file:`/usr/local/bin/python`, it will assume that the libraries are in "
":file:`/usr/local/lib/python{X.Y}`.  (In fact, this particular path is also "
"the \"fallback\" location, used when no executable file named :file:`python`"
" is found along :envvar:`PATH`.)  The user can override this behavior by "
"setting the environment variable :envvar:`PYTHONHOME`, or insert additional "
"directories in front of the standard path by setting :envvar:`PYTHONPATH`."
msgstr ""
"例えば、 Python 実行形式が :file:`/usr/local/bin/python` で見つかったとすると、 "
":c:func:`Py_Initialize` はライブラリが :file:`/usr/local/lib/python{X.Y}` "
"にあるものと仮定します。 (実際には、このパスは \"フォールバック (fallback)\" のライブラリ位置でもあり、 :file:`python`"
" が :envvar:`PATH` 上に無い場合に使われます。) ユーザは :envvar:`PYTHONHOME` "
"を設定することでこの動作をオーバライドしたり、 :envvar:`PYTHONPATH` "
"を設定して追加のディレクトリを標準モジュール検索パスの前に挿入したりできます。"

#: ../../c-api/intro.rst:695
msgid ""
"The embedding application can steer the search by calling "
"``Py_SetProgramName(file)`` *before* calling  :c:func:`Py_Initialize`.  Note"
" that :envvar:`PYTHONHOME` still overrides this and :envvar:`PYTHONPATH` is "
"still inserted in front of the standard path.  An application that requires "
"total control has to provide its own implementation of :c:func:`Py_GetPath`,"
" :c:func:`Py_GetPrefix`, :c:func:`Py_GetExecPrefix`, and "
":c:func:`Py_GetProgramFullPath` (all defined in :file:`Modules/getpath.c`)."
msgstr ""
"埋め込みを行うアプリケーションでは、 :c:func:`Py_Initialize` を呼び出す *前に* "
"``Py_SetProgramName(file)``  を呼び出すことで、上記の検索を操作できます。この埋め込みアプリケーションでの設定は依然として "
":envvar:`PYTHONHOME`  でオーバライドでき、標準のモジュール検索パスの前には以前として :envvar:`PYTHONPATH` "
"が挿入されるので注意してください。アプリケーションでモジュール検索パスを完全に制御したいのなら、独自に :c:func:`Py_GetPath`, "
":c:func:`Py_GetPrefix`, :c:func:`Py_GetExecPrefix`,  および "
":c:func:`Py_GetProgramFullPath`  の実装を提供しなければなりません (これらは全て "
":file:`Modules/getpath.c` で定義されています)。"

#: ../../c-api/intro.rst:705
msgid ""
"Sometimes, it is desirable to \"uninitialize\" Python.  For instance,  the "
"application may want to start over (make another call to "
":c:func:`Py_Initialize`) or the application is simply done with its  use of "
"Python and wants to free memory allocated by Python.  This can be "
"accomplished by calling :c:func:`Py_FinalizeEx`.  The function "
":c:func:`Py_IsInitialized` returns true if Python is currently in the "
"initialized state.  More information about these functions is given in a "
"later chapter. Notice that :c:func:`Py_FinalizeEx` does *not* free all "
"memory allocated by the Python interpreter, e.g. memory allocated by "
"extension modules currently cannot be released."
msgstr ""
"たまに、 Python を初期化前の状態にもどしたいことがあります。例えば、あるアプリケーションでは実行を最初からやりなおし (start over) "
"させる (:c:func:`Py_Initialize` をもう一度呼び出させる) ようにしたいかもしれません。あるいは、アプリケーションが "
"Python を一旦使い終えて、Python が確保したメモリを解放させたいかもしれません。 :c:func:`Py_FinalizeEx` "
"を使うとこうした処理を実現できます。また、関数 :c:func:`Py_IsInitialized`  は、Python "
"が現在初期化済みの状態にある場合に真を返します。これらの関数についてのさらなる情報は、後の章で説明します。 "
":c:func:`Py_FinalizeEx` がPythonインタプリタに確保された全てのメモリを *解放するわけではない* "
"ことに注意してください。例えば、拡張モジュールによって確保されたメモリは、現在のところ解放する事ができません。"

#: ../../c-api/intro.rst:719
msgid "Debugging Builds"
msgstr "デバッグ版ビルド (Debugging Builds)"

#: ../../c-api/intro.rst:721
msgid ""
"Python can be built with several macros to enable extra checks of the "
"interpreter and extension modules.  These checks tend to add a large amount "
"of overhead to the runtime so they are not enabled by default."
msgstr ""
"インタプリタと拡張モジュールに対しての追加チェックをするためのいくつかのマクロを有効にしてPythonをビルドすることができます。これらのチェックは、実行時に大きなオーバーヘッドを生じる傾向があります。なので、デフォルトでは有効にされていません。"

#: ../../c-api/intro.rst:725
msgid ""
"A full list of the various types of debugging builds is in the file "
":file:`Misc/SpecialBuilds.txt` in the Python source distribution. Builds are"
" available that support tracing of reference counts, debugging the memory "
"allocator, or low-level profiling of the main interpreter loop.  Only the "
"most frequently-used builds will be described in the remainder of this "
"section."
msgstr ""
"Pythonデバッグ版ビルドの全ての種類のリストが、Pythonソース配布(source distribution)の中の "
":file:`Misc/SpecialBuilds.txt` "
"にあります。参照カウントのトレース、メモリアロケータのデバッグ、インタプリタのメインループの低レベルプロファイリングが利用可能です。よく使われるビルドについてのみ、この節の残りの部分で説明します。"

#: ../../c-api/intro.rst:731
msgid ""
"Compiling the interpreter with the :c:macro:`Py_DEBUG` macro defined "
"produces what is generally meant by \"a debug build\" of Python. "
":c:macro:`Py_DEBUG` is enabled in the Unix build by adding ``--with-"
"pydebug`` to the :file:`./configure` command.  It is also implied by the "
"presence of the not-Python-specific :c:macro:`_DEBUG` macro.  When "
":c:macro:`Py_DEBUG` is enabled in the Unix build, compiler optimization is "
"disabled."
msgstr ""
"インタプリタを :c:macro:`Py_DEBUG` マクロを有効にしてコンパイルすると、一般的に「デバッグビルド」といわれるPythonができます。"
" Unix では、 :file:`./configure` コマンドに ``--with-pydebug`` を追加することで、 "
":c:macro:`Py_DEBUG` が有効になります。その場合、暗黙的にPython専用ではない :c:macro:`_DEBUG` "
"も有効になります。 Unix ビルドでは、 :c:macro:`Py_DEBUG` が有効な場合、コンパイラの最適化が無効になります。"

#: ../../c-api/intro.rst:738
msgid ""
"In addition to the reference count debugging described below, the following "
"extra checks are performed:"
msgstr "あとで説明する参照カウントデバッグの他に、以下の追加チェックも有効になります:"

#: ../../c-api/intro.rst:741
msgid "Extra checks are added to the object allocator."
msgstr "object allocator に対する追加チェック。"

#: ../../c-api/intro.rst:743
msgid "Extra checks are added to the parser and compiler."
msgstr "パーサーとコンパイラに対する追加チェック。"

#: ../../c-api/intro.rst:745
msgid ""
"Downcasts from wide types to narrow types are checked for loss of "
"information."
msgstr "情報損失のために、大きい型から小さい型へのダウンキャストに対するチェック。"

#: ../../c-api/intro.rst:747
msgid ""
"A number of assertions are added to the dictionary and set implementations. "
"In addition, the set object acquires a :meth:`test_c_api` method."
msgstr ""
"辞書(dict)と集合(set)の実装に対する、いくつもの assertion の追加。加えて、集合オブジェクトに :meth:`test_c_api`"
" メソッドが追加されます。"

#: ../../c-api/intro.rst:750
msgid "Sanity checks of the input arguments are added to frame creation."
msgstr "フレームを作成する時の、引数の健全性チェック。"

#: ../../c-api/intro.rst:752
msgid ""
"The storage for ints is initialized with a known invalid pattern to catch "
"reference to uninitialized digits."
msgstr "初期化されていない数に対する参照を検出するために、整数のストレージが特定の妥当でないパターンで初期化されます。"

#: ../../c-api/intro.rst:755
msgid ""
"Low-level tracing and extra exception checking are added to the runtime "
"virtual machine."
msgstr "低レベルトレースと追加例外チェックがVM runtimeに追加されます。"

#: ../../c-api/intro.rst:758
msgid "Extra checks are added to the memory arena implementation."
msgstr "メモリアリーナ(memory arena)の実装に対する追加チェック。"

#: ../../c-api/intro.rst:760
msgid "Extra debugging is added to the thread module."
msgstr "threadモジュールに対する追加デバッグ機能."

#: ../../c-api/intro.rst:762
msgid "There may be additional checks not mentioned here."
msgstr "ここで言及されていない追加チェックもあるでしょう。"

#: ../../c-api/intro.rst:764
msgid ""
"Defining :c:macro:`Py_TRACE_REFS` enables reference tracing.  When defined, "
"a circular doubly linked list of active objects is maintained by adding two "
"extra fields to every :c:type:`PyObject`.  Total allocations are tracked as "
"well.  Upon exit, all existing references are printed.  (In interactive mode"
" this happens after every statement run by the interpreter.)  Implied by "
":c:macro:`Py_DEBUG`."
msgstr ""
":c:macro:`Py_TRACE_REFS` を宣言すると、参照トレースが有効になります。全ての :c:type:`PyObject` "
"に二つのフィールドを追加することで、使用中のオブジェクトの循環二重連結リストが管理されます。全ての割り当て(allocation)がトレースされます。終了時に、全ての残っているオブジェクトが表示されます。"
" (インタラクティブモードでは、インタプリタによる文の実行のたびに表示されます) Py_TRACE_REFS は :c:macro:`Py_DEBUG`"
" によって暗黙的に有効になります。"

#: ../../c-api/intro.rst:770
msgid ""
"Please refer to :file:`Misc/SpecialBuilds.txt` in the Python source "
"distribution for more detailed information."
msgstr ""
"より詳しい情報については、Pythonのソース配布(source distribution)の中の "
":file:`Misc/SpecialBuilds.txt` を参照してください。"