Commits

Nozomu Kaneko  committed 9ce1ab1

misc fix

  • Participants
  • Parent commits e647603

Comments (0)

Files changed (17)

 このドキュメントや、 Python 自体のバグ報告については、 :ref:`reporting-bugs`
 を参照してください。
 
-.. note::
-   訳注: 日本語訳の問題については、 Google Project Hosting 上の Issue Tracker
-   <http://code.google.com/p/python-doc-ja/issues/entry> に登録するか、
-   python-doc-jp@python.jp にメールで報告をお願いします。
+.. .. note::
+..    訳注: 日本語訳の問題については、 Google Project Hosting 上の Issue Tracker
+..    <http://code.google.com/p/python-doc-ja/issues/entry> に登録するか、
+..    python-doc-jp@python.jp にメールで報告をお願いします。
 
 .. including the ACKS file here so that it can be maintained separately
 .. include:: ACKS.txt
 詳細な課題解決ワークフローについては、 http://www.python.org/dev/workflow/
 を参照してください。
 
-.. rubric:: 注記
+.. .. rubric:: 注記
 
-.. [#] 訳注:原文ではextension moduleですが、これはC言語で書かれたモジュールという
-       意味ではなくて、広義で非標準ライブラリを指しているかもしれません。
+.. .. [#] 訳注:原文ではextension moduleですが、これはC言語で書かれたモジュールという
+..        意味ではなくて、広義で非標準ライブラリを指しているかもしれません。
 
 各バグ報告は開発者に割り当てられ、その人がその問題を修正するのに何が必要かを決定します。
 そのバグ報告に対して何かアクションがあるたびに、更新情報があなたにメールで届きます。

File c-api/arg.rst

           return result;
       }
 
-   この例における :c:func:`PyArg_UnpackTuple` 呼び出しは、 :c:func:`PyArg_ParseTuple` を使った以下の呼び出し::
+   この例における :c:func:`PyArg_UnpackTuple` 呼び出しは、 :c:func:`PyArg_ParseTuple` を使った以下の呼び出しと全く等価です。::
 
       PyArg_ParseTuple(args, "O|O:ref", &object, &callback)
 
-   と全く等価です。
-
    .. versionadded:: 2.2
 
    .. versionchanged:: 2.5

File c-api/dict.rst

    反復可能オブジェクト(iterable object) を生成する反復可能オブジェクトでなければなりません。重複するキーが存在する場合、 *override*
    が真ならば先に出現したキーを使い、そうでない場合は後に出現したキーを使います。成功した場合には ``0`` を返し、例外が送出された場合には ``-1``
    を返します。
-
    (戻り値以外は) 等価な Python コードを書くと、以下のようになります::
 
       def PyDict_MergeFromSeq2(a, seq2, override):

File c-api/init.rst

 .. c:function:: const char* Py_GetCopyright()
 
    現在の Python バージョンに対する公式の著作権表示文字列、例えば
-   ``'Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam'`` を返します。
+   以下を返します。
+
+   ``'Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam'``
 
    .. index:: single: copyright (in module sys)
 
 .. c:function:: const char* Py_GetCompiler()
 
    現在使っているバージョンの Python をビルドする際に用いたコンパイラを示す文字列を、
-   角括弧で囲った文字列を返します。例えば::
+   角括弧で囲った文字列を返します。例えば以下のようになります。 ::
 
       "[GCC 2.7.2.2]"
 
-   になります。
 
    .. index:: single: version (in module sys)
 
 
 .. c:function:: const char* Py_GetBuildInfo()
 
-   現在使っている Python インタプリタインスタンスの、シーケンス番号とビルド日時に関する情報を返します。例えば ::
+   現在使っている Python インタプリタインスタンスの、シーケンス番号とビルド日時に関する情報を返します。例えば以下のようになります。 ::
 
       "#67, Aug  1 1997, 22:34:28"
 
-   になります。
 
    .. index:: single: version (in module sys)
 
    可能となるようにします。
    この関数はスレッド内で何度でも呼び出すことができますが、必ず全ての呼び出しに対応して
    :c:func:`PyGILState_Release` を呼び出す必要があります。
-
    通常、 :c:func:`PyGILState_Ensure` 呼び出しと
    :c:func:`PyGILState_Release` 呼び出しの間でこれ以外のスレッド関連API
    を使用することができますが、Release()の前にスレッド状態は復元されていな
    スレッド内で非同期的に例外を送出します。 *id* 引数はターゲットとなるスレッドのスレッド id です; *exc* は送出する例外オブジェクトです。
    この関数は *exc* に対する参照を一切盗み取りません。素朴な間違いを防ぐため、この関数を呼び出すには独自に C 拡張モジュールを書かねばなりません。
    GIL を保持した状態で呼び出さなければなりません。
-
    変更を受けたスレッド状態の数を返します; これは普通は1ですが、スレッドidが見つからなかった場合は0になります。もし *exc* が
    :const:`NULL` であれば、そのスレッドで保留されている例外があればクリアします。この場合は例外は発生しません。
 
 
    例外が送出された際の :c:type:`Py_tracefunc` の *what* の値です。現在実行されているフレームで例外がセットされ、何らかのバイトコードが
    処理された後に、 *what* にこの値がセットされた状態でコールバック関数が呼び出されます。
-
    この結果、例外の伝播によって Python が呼び出しスタックを逆戻りする際に、各フレームから処理が戻るごとにコールバック関数が呼び出されます。
    トレース関数だけがこれらのイベントを受け取ります; プロファイラはこの種のイベントを必要としません。
 

File c-api/intro.rst

 を記述する、という目的です。第二は、より大規模なアプリケーション内で Python
 を構成要素 (component) として利用するという目的です; このテクニックは、
 一般的にはアプリケーションへの Python の埋め込み (:dfn:`embedding`) と呼びます。
+
 拡張モジュールの作成は比較的わかりやすいプロセスで、 "手引書 (cookbook)"
 的なアプローチでうまく実現できます。作業をある程度まで自動化してくれる
 ツールもいくつかあります。一方、他のアプリケーションへの Python の
 
 逆に、ある関数呼び出しで、あるオブジェクトへの参照を呼び出される関数に渡す際には、二つの可能性: 関数がオブジェクトへの参照を *盗み取る* (steal)
 場合と、そうでない場合があります。
-
 *参照を盗む* とは、関数に参照を渡したときに、参照の所有者がその関数になったと仮定し、関数の呼び出し元には所有権がなくなるということです。
 
 .. index::

File c-api/marshal.rst

 
 以下の関数を使うと、整列化された値を読み戻せます。
 
-.. XXX What about error detection?  It appears that reading past the end
-.. of the file will always result in a negative numeric value (where
-.. that's relevant), but it's not clear that negative values won't be
-.. handled properly when there's no error.  What's the right way to tell?
-.. Should only non-negative values be written using these routines?
+XXX What about error detection?  It appears that reading past the end of the
+file will always result in a negative numeric value (where that's relevant),
+but it's not clear that negative values won't be handled properly when there's
+no error.  What's the right way to tell? Should only non-negative values be
+written using these routines?
+
 
 .. c:function:: long PyMarshal_ReadLongFromFile(FILE *file)
 

File c-api/slice.rst

 .. c:function:: int PySlice_GetIndicesEx(PySliceObject *slice, Py_ssize_t length, Py_ssize_t *start, Py_ssize_t *stop, Py_ssize_t *step, Py_ssize_t *slicelength)
 
    :c:func:`PySlice_GetIndices` の置き換えとして使える関数です。
-
    スライスオブジェクト *slice* における *start*, *stop*,  および *step* のインデクス値を取得します。このときシーケンスの
    長さを *length* と仮定します。スライスの長さを *slicelength* に記憶します。境界をはみだしたインデクスは、通常のスライスを扱うのと
    同じ一貫したやり方でクリップされます。

File c-api/string.rst

    *buffer* は *obj* の内部文字列バッファを参照し、バッファのコピーを参照するわけではありません。
    ``PyString_FromStringAndSize(NULL, size)`` を使って生成した文字列でない限り、バッファ内のデータはいかなる変更も
    してはなりません。この文字列をデアロケートしてはなりません。
-
    *string* が Unicode オブジェクトの場合、この関数は *string* のデフォルトエンコーディング版を計算し、
    デフォルトエンコーディング版に対して操作を行います。 *string* が文字列オブジェクトですらない場合、
    :c:func:`PyString_AsStringAndSize` は ``-1`` を返して :exc:`TypeError` を送出します。

File c-api/structures.rst

    から扱う必要がある際に必要な情報が入っています。通常に "リリースされている"
    ビルドでは、この構造体にはオブジェクトの参照カウントと、オブジェクトに
    対応する型オブジェクトだけが入っています。
-
    ``PyObject_HEAD`` マクロ展開で定義されているフィールドに対応します。
 
 

File c-api/typeobj.rst

    基本サイズには、 :c:macro:`PyObject_HEAD` マクロまたは  :c:macro:`PyObject_VAR_HEAD` マクロ
    (インスタンス構造体を宣言するのに使ったどちらかのマクロ) で宣言されているフィールドが入っています。さらに、 :attr:`_ob_prev` および
    :attr:`_ob_next` フィールドがある場合、これらのフィールドもサイズに加算されます。
-
    従って、 :attr:`tp_basicsize` の正しい初期化パラメタを得るには、インスタンスデータのレイアウトを宣言するのに使う構造体に対して
    ``sizeof`` 演算子を使うしかありません。基本サイズには、GC ヘッダサイズは入っていません (これは Python 2.2
    からの新しい仕様です; 2.1 や 2.0 では、GC ヘッダサイズは :attr:`tp_basicsize` に入っていました)。
    この関数はクラスにおける  :meth:`__init__` メソッドに対応します。 :meth:`__init__` と同様、 :meth:`__init__`
    を呼び出さずにインスタンスを作成できます。また、 :meth:`__init__` を再度呼び出してインスタンスの再初期化もできます。
 
-   関数のシグネチャは ::
+   関数のシグネチャは以下の通りです。 ::
 
       int tp_init(PyObject *self, PyObject *args, PyObject *kwds)
 
-   です。
-
    *self* 引数は初期化するインスタンスです; *args* および *kwds* 引数は、
    :meth:`__init__` を呼び出す際の固定引数およびキーワード引数です。
 
 
    オプションのフィールドです。ポインタで、インスタンスのメモリ確保関数を指します。
 
-   関数のシグネチャは ::
+   関数のシグネチャは以下の通りです。 ::
 
       PyObject *tp_alloc(PyTypeObject *self, Py_ssize_t nitems)
 
-   です。
-
    この関数の目的は、メモリ確保をメモリ初期化から分離することにあります。この関数は、インスタンス用の的確なサイズを持ち、適切にバイト整列
    され、ゼロで初期化され、ただし :attr:`ob_refcnt` を ``1``  にセットされ、 :attr:`ob_type` が型引数 (type
    argument) にセットされているようなメモリブロックを返さねばなりません。型の :attr:`tp_itemsize`
    このフィールドが *NULL* を指している型では、型を呼び出して新たなインスタンスを生成できません; こうした型では、おそらくファクトリ
    関数のように、インスタンスを生成する他の方法があるはずです。
 
-   関数のシグネチャは ::
+   関数のシグネチャは以下の通りです。 ::
 
       PyObject *tp_new(PyTypeObject *subtype, PyObject *args, PyObject *kwds)
 
-   です。
-
    引数 *subtype* は生成するオブジェクトの型です;  *args* および *kwds* 引数は、型を呼び出すときの
    固定引数およびキーワード引数です。サブタイプは :attr:`tp_new` 関数を呼び出すときに使う型と等価というわけではないので注意してください;
    :attr:`tp_new` 関数を呼び出すときに使う型 (と無関係ではない)  サブタイプのこともあります。
 
    オプションのフィールドです。ポインタで、インスタンスのメモリ解放関数を指します。
 
-   この関数のシグネチャは少し変更されています; Python 2.2 および 2.2.1 では、シグネチャは :c:type:`destructor` ::
+   この関数のシグネチャは少し変更されています; Python 2.2 および 2.2.1 では、シグネチャは :c:type:`destructor` でしたが、 ::
 
       void tp_free(PyObject *)
 
-   でしたが、 Python 2.3 以降では、シグネチャは :c:type:`freefunc`::
+   Python 2.3 以降では、シグネチャは :c:type:`freefunc` になっています ::
 
       void tp_free(void *)
 
-   になっています。
-
    両方のバージョンと互換性のある初期値は ``_PyObject_Del`` です。 ``_PyObject_Del`` の定義は Python 2.3
    で適切に対応できるよう変更されました。
 
    :attr:`tp_flags` フィールドを見て、 :const:`Py_TPFLAGS_HAVE_GC`
    フラグビットを調べるだけで十分です。しかし、静的なメモリ確保と動的なメモリ確保が混じっているインスタンスを持つような型や、
    静的にメモリ確保されたインスタンスは収集できません。こうした型では、このフィールドに関数を定義しなければなりません; 関数はインスタンスが収集可能の場合には
-   ``1`` を、収集不能の場合には ``0`` を返さねばなりません。シグネチャは ::
+   ``1`` を、収集不能の場合には ``0`` を返さねばなりません。シグネチャは以下の通りです。 ::
 
       int tp_is_gc(PyObject *self)
 
-   です。
-
    (上記のような型の例は、型オブジェクト自体です。メタタイプ :c:data:`PyType_Type` は、型のメモリ確保が静的か動的かを
    区別するためにこの関数を定義しています。)
 

File c-api/unicode.rst

    もし、 *mapping* が *NULL* だった場合、latin-1 でデコードされます。それ以外の場合では、 *mapping* は byte に対する辞書マップ
    (訳注: s に含まれる文字の unsigned な値を int 型でキーとして、値として変換対象の Unicode 文字を表す Unicode 文字列になっているような辞書)
    か、ルックアップテーブルとして扱われる Unicode 文字列です。
-
    文字列 (訳注: mapping が Unicode 文字列として渡された場合) の長さより大きい byte 値や、(訳注: mappingにしたがって変換した結果が)
    U+FFFE "characters" になる Byte値は、"定義されていない対応付け (undefined mapping)" として扱われます。
 

File copyright.rst

 Copyright © 1991-1995 Stichting Mathematisch Centrum. All rights reserved.
 
 
-Japanese translation is:
-Copyright © 2003-2009 Python Document Japanese Translation Project. All rights reserved.
+.. Japanese translation is:
+.. Copyright © 2003-2009 Python Document Japanese Translation Project. All rights reserved.
 
 -------
 

File distutils/apiref.rst

 
       *output_libname* はライブラリ名で、ファイル名ではありません; ファイ
       ル名はライブラリ名から作られます。 *output_dir* はライブラリファイルが起かれるディレクトリです。
+
       *debug* はブール値です。真なら、デバッグ情報がライブラリに含まれます(ほとんどのプラットフォームではコンパイルステップで意味をもちます:
       *debug* フラグは一貫性のためにここにもあります。)。
 
    .. warning::
 
       Unix ではデバイスをまたがる移動は :func:`copy_file` を利用して扱っています。
-
       (todo:他のシステムではどうなっている?)
 
 

File distutils/examples.rst

                     foo.py
                     bar.py
 
-適切な setup スクリプトは、 ::
+適切な setup スクリプトは、以下のようになるでしょう。 ::
 
    from distutils.core import setup
    setup(name='foobar',
          packages=['foobar'],
          )
 
-のようになるでしょう。
 
 .. %
 
            foo.py
            bar.py
 
-この場合、 setup スクリプトは ::
+この場合、 setup スクリプトは以下のようになるでしょう。 ::
 
    from distutils.core import setup
    setup(name='foobar',
          packages=['foobar'],
          )
 
-のようになるでしょう。 (空文字列も現在のディレクトリを表します。)
+(空文字列も現在のディレクトリを表します。)
 
 .. %
 
 
 拡張モジュールは、 :option:`ext_modules` オプションを使って指定します。 :option:`package_dir`
 は、拡張モジュールのソースファイルをどこで探すかには影響しません; pure Python モジュールのソースのみに影響します。
-もっとも単純なケースでは、単一の C ソースファイルで書かれた単一の拡張モジュールは::
+もっとも単純なケースでは、単一の C ソースファイルで書かれた単一の拡張モジュールは以下のようになります。 ::
 
    <root>/
            setup.py
            foo.c
 
-になります。
 
 .. %
 
-:mod:`foo` 拡張をルートパッケージ下に所属させたい場合、 setup  スクリプトは ::
+:mod:`foo` 拡張をルートパッケージ下に所属させたい場合、 setup  スクリプトは以下のようになります。 ::
 
    from distutils.core import setup
    from distutils.extension import Extension
          ext_modules=[Extension('foo', ['foo.c'])],
          )
 
-になります。
 
 .. %
 
-同じソースツリーレイアウトで、この拡張モジュールを :mod:`foopkg` の下に置き、拡張モジュールの名前を変えるには::
+同じソースツリーレイアウトで、この拡張モジュールを :mod:`foopkg` の下に置き、拡張モジュールの名前を変えるには以下のようにします。 ::
 
    from distutils.core import setup
    from distutils.extension import Extension
          ext_modules=[Extension('foopkg.foo', ['foo.c'])],
          )
 
-のようにします。
 
 .. %
 

File distutils/introduction.rst

   例を参照してください)
 
 このモジュールのソースコード配布物を作成するには、上記のコードが入った setup スクリプト :file:`setup.py`
-を作成して、以下のコマンド::
+を作成して、以下のコマンドをターミナルから実行します。 ::
 
    python setup.py sdist
 
-を実行します。
-
 .. %
 
 この操作を行うと、アーカイブファイル (例えば Unixでは tarball、Windows では ZIP ファイル) を作成します。アーカイブファイル
 (:command:`bdist_rpm` コマンドは :command:`rpm` コマンドを使うため、 Red Hat Linux や SuSE
 Linux、 Mandrake Linux といった RPM ベースのシステムで実行しなければなりません)
 
-どの配布形式が利用できるかは、 ::
+どの配布形式が利用できるかは、以下のコマンドを実行すれば分かります。 ::
 
    python setup.py bdist --help-formats
 
-を実行すれば分かります。
-
 .. %
 
 

File distutils/setupscript.rst

 .. %
 
 もう一つの規約のあり方は :mod:`foo` パッケージを :file:`lib` に置き換え、 :mod:`foo.bar` パッケージが
-:file:`lib/bar` にある、などとするものです。このような規約は、 setup スクリプトでは ::
+:file:`lib/bar` にある、などとするものです。このような規約は、 setup スクリプトでは以下のように書きます。 ::
 
    package_dir = {'foo': 'lib'}
 
-のように書きます。 :option:`package_dir` 辞書に ``package: dir`` のようなエントリがあると、 *package*
+:option:`package_dir` 辞書に ``package: dir`` のようなエントリがあると、 *package*
 の下にある全てのパッケージに対してこの規則が暗黙のうちに適用され、その結果 :mod:`foo.bar` の場合が自動的に処理されます。この例では、
 ``packages = ['foo', 'foo.bar']`` は、 Distutils に :file:`lib/__init__.py` と
 :file:`lib/bar/__init__.py` を探すように指示します。 (:option:`package_dir`
    Extension('foo', ['foo.c'], include_dirs=['include'])
 
 ここには絶対パスも指定できます; 例えば、自分の拡張モジュールが、 :file:`/usr` の下にX11R6 をインストールした Unix システムだけで
-ビルドされると知っていれば、 ::
+ビルドされると知っていれば、以下のように書けます。 ::
 
    Extension('foo', ['foo.c'], include_dirs=['/usr/include/X11'])
 
-のように書けます。
-
-自分のコードを配布する際には、このような可搬性のない使い方は避けるべきです: おそらく、 C のコードを  ::
+自分のコードを配布する際には、このような可搬性のない使い方は避けるべきです: おそらく、 C のコードを以下のように書いた方がましでしょう。 ::
 
    #include <X11/Xlib.h>
 
-のように書いた方がましでしょう。
-
 他の Python 拡張モジュール由来のヘッダを include する必要があるなら、 Distutils の
 :command:`install_header` コマンドが一貫した方法でヘッダファイルをインストールするという事実を活用できます。例えば、
 Numerical Python のヘッダファイルは、 (標準的な Unix がインストールされた環境では)
 :file:`/usr/local/include/python1.5/Numerical` にインストールされます。 (実際の場所は、プラットフォームやどの
 Python をインストールしたかで異なります。) Python の include ディレクトリ --- 今の例では
 :file:`/usr/local/include/python1.5` --- は、 Python 拡張モジュールを
-ビルドする際に常にヘッダファイル検索パスに取り込まれるので、 C コードを書く上でもっともよいアプローチは、  ::
+ビルドする際に常にヘッダファイル検索パスに取り込まれるので、 C コードを書く上でもっともよいアプローチは、以下となります。  ::
 
    #include <Numerical/arrayobject.h>
 
-となります。
-
 :file:`Numerical` インクルードディレクトリ自体をヘッダ検索パスに置きたいのなら、このディレクトリを Distutils の
 :mod:`distutils.sysconfig`  モジュールを使って見つけさせられます::
 
                             ('HAVE_STRFTIME', None)],
              undef_macros=['HAVE_FOO', 'HAVE_BAR'])
 
-は、全ての C ソースコードファイルの先頭に、以下のマクロ::
+は、全ての C ソースコードファイルの先頭に、以下のマクロがあるのと同じになります。 ::
 
    #define NDEBUG 1
    #define HAVE_STRFTIME
    #undef HAVE_FOO
    #undef HAVE_BAR
 
-があるのと同じになります。
-
 
 ライブラリオプション
 --------------------