pytho****@googl*****
pytho****@googl*****
2011年 12月 11日 (日) 10:55:22 JST
3 new revisions: Revision: b056d59baf92 Author: cocoatomo <cocoa****@gmail*****> Date: Sat Dec 10 17:53:36 2011 Log: fix c markups http://code.google.com/p/python-doc-ja/source/detail?r=b056d59baf92 Revision: 5b3e66c2379b Author: cocoatomo <cocoa****@gmail*****> Date: Sat Dec 10 17:54:14 2011 Log: translate up to column identifier http://code.google.com/p/python-doc-ja/source/detail?r=5b3e66c2379b Revision: 4d8afa458e7b Author: cocoatomo <cocoa****@gmail*****> Date: Sat Dec 10 17:54:39 2011 Log: merge http://code.google.com/p/python-doc-ja/source/detail?r=4d8afa458e7b ============================================================================== Revision: b056d59baf92 Author: cocoatomo <cocoa****@gmail*****> Date: Sat Dec 10 17:53:36 2011 Log: fix c markups http://code.google.com/p/python-doc-ja/source/detail?r=b056d59baf92 Modified: /whatsnew/2.5.rst ======================================= --- /whatsnew/2.5.rst Sat Dec 10 06:58:42 2011 +++ /whatsnew/2.5.rst Sat Dec 10 17:53:36 2011 @@ -903,13 +903,13 @@ This change most strongly affects authors of C extension modules. Python strings and container types such as lists and tuples now use :c:type:`Py_ssize_t` to store their size. Functions such as -:cfunc:`PyList_Size` now return :c:type:`Py_ssize_t`. Code in extension modules +:c:func:`PyList_Size` now return :c:type:`Py_ssize_t`. Code in extension modules may therefore need to have some variables changed to :c:type:`Py_ssize_t`. -The :cfunc:`PyArg_ParseTuple` and :cfunc:`Py_BuildValue` functions have a new -conversion code, ``n``, for :c:type:`Py_ssize_t`. :cfunc:`PyArg_ParseTuple`'s +The :c:func:`PyArg_ParseTuple` and :c:func:`Py_BuildValue` functions have a new +conversion code, ``n``, for :c:type:`Py_ssize_t`. :c:func:`PyArg_ParseTuple`'s ``s#`` and ``t#`` still output :c:type:`int` by default, but you can define the -macro :cmacro:`PY_SSIZE_T_CLEAN` before including :file:`Python.h` to make +macro :c:macro:`PY_SSIZE_T_CLEAN` before including :file:`Python.h` to make them return :c:type:`Py_ssize_t`. :pep:`353` has a section on conversion guidelines that extension authors should @@ -955,7 +955,7 @@ A corresponding :attr:`nb_index` slot was added to the C-level :c:type:`PyNumberMethods` structure to let C extensions implement this protocol. -:cfunc:`PyNumber_Index(obj)` can be used in extension code to call the +:c:func:`PyNumber_Index(obj)` can be used in extension code to call the :meth:`__index__` function and retrieve its result. @@ -1179,7 +1179,7 @@ (Contributed by Bob Ippolito at the NeedForSpeed sprint.) * The :mod:`re` module got a 1 or 2% speedup by switching to Python's allocator - functions instead of the system's :cfunc:`malloc` and :cfunc:`free`. + functions instead of the system's :c:func:`malloc` and :c:func:`free`. (Contributed by Jack Diederich at the NeedForSpeed sprint.) * The code generator's peephole optimizer now performs simple constant folding @@ -1203,7 +1203,7 @@ Sean Reifschneider at the NeedForSpeed sprint.) * Importing now caches the paths tried, recording whether they exist or not so - that the interpreter makes fewer :cfunc:`open` and :cfunc:`stat` calls on + that the interpreter makes fewer :c:func:`open` and :c:func:`stat` calls on startup. (Contributed by Martin von Löwis and Georg Brandl.) .. Patch 921466 @@ -1568,7 +1568,7 @@ reporting ``('CPython', 'trunk', '45313:45315')``. This information is also available to C extensions via the - :cfunc:`Py_GetBuildInfo` function that returns a string of build information + :c:func:`Py_GetBuildInfo` function that returns a string of build information like this: ``"trunk:45355:45356M, Apr 13 2006, 07:42:19"``. (Contributed by Barry Warsaw.) @@ -2113,10 +2113,10 @@ discusses the design. To start learning about the code, read the definition of the various AST nodes in :file:`Parser/Python.asdl`. A Python script reads this file and generates a set of C structure definitions in - :file:`Include/Python-ast.h`. The :cfunc:`PyParser_ASTFromString` and - :cfunc:`PyParser_ASTFromFile`, defined in :file:`Include/pythonrun.h`, take + :file:`Include/Python-ast.h`. The :c:func:`PyParser_ASTFromString` and + :c:func:`PyParser_ASTFromFile`, defined in :file:`Include/pythonrun.h`, take Python source as input and return the root of an AST representing the contents. - This AST can then be turned into a code object by :cfunc:`PyAST_Compile`. For + This AST can then be turned into a code object by :c:func:`PyAST_Compile`. For more information, read the source code, and then ask questions on python-dev. The AST code was developed under Jeremy Hylton's management, and implemented by @@ -2138,55 +2138,55 @@ Note that this change means extension modules must be more careful when allocating memory. Python's API has many different functions for allocating - memory that are grouped into families. For example, :cfunc:`PyMem_Malloc`, - :cfunc:`PyMem_Realloc`, and :cfunc:`PyMem_Free` are one family that allocates - raw memory, while :cfunc:`PyObject_Malloc`, :cfunc:`PyObject_Realloc`, and - :cfunc:`PyObject_Free` are another family that's supposed to be used for + memory that are grouped into families. For example, :c:func:`PyMem_Malloc`, + :c:func:`PyMem_Realloc`, and :c:func:`PyMem_Free` are one family that allocates + raw memory, while :c:func:`PyObject_Malloc`, :c:func:`PyObject_Realloc`, and + :c:func:`PyObject_Free` are another family that's supposed to be used for creating Python objects. Previously these different families all reduced to the platform's - :cfunc:`malloc` and :cfunc:`free` functions. This meant it didn't matter if - you got things wrong and allocated memory with the :cfunc:`PyMem` function but - freed it with the :cfunc:`PyObject` function. With 2.5's changes to obmalloc, + :c:func:`malloc` and :c:func:`free` functions. This meant it didn't matter if + you got things wrong and allocated memory with the :c:func:`PyMem` function but + freed it with the :c:func:`PyObject` function. With 2.5's changes to obmalloc, these families now do different things and mismatches will probably result in a segfault. You should carefully test your C extension modules with Python 2.5. -* The built-in set types now have an official C API. Call :cfunc:`PySet_New` - and :cfunc:`PyFrozenSet_New` to create a new set, :cfunc:`PySet_Add` and - :cfunc:`PySet_Discard` to add and remove elements, and :cfunc:`PySet_Contains` - and :cfunc:`PySet_Size` to examine the set's state. (Contributed by Raymond +* The built-in set types now have an official C API. Call :c:func:`PySet_New` + and :c:func:`PyFrozenSet_New` to create a new set, :c:func:`PySet_Add` and + :c:func:`PySet_Discard` to add and remove elements, and :c:func:`PySet_Contains` + and :c:func:`PySet_Size` to examine the set's state. (Contributed by Raymond Hettinger.) * C code can now obtain information about the exact revision of the Python - interpreter by calling the :cfunc:`Py_GetBuildInfo` function that returns a + interpreter by calling the :c:func:`Py_GetBuildInfo` function that returns a string of build information like this: ``"trunk:45355:45356M, Apr 13 2006, 07:42:19"``. (Contributed by Barry Warsaw.) * Two new macros can be used to indicate C functions that are local to the current file so that a faster calling convention can be used. - :cfunc:`Py_LOCAL(type)` declares the function as returning a value of the + :c:func:`Py_LOCAL(type)` declares the function as returning a value of the specified *type* and uses a fast-calling qualifier. - :cfunc:`Py_LOCAL_INLINE(type)` does the same thing and also requests the - function be inlined. If :cfunc:`PY_LOCAL_AGGRESSIVE` is defined before + :c:func:`Py_LOCAL_INLINE(type)` does the same thing and also requests the + function be inlined. If :c:func:`PY_LOCAL_AGGRESSIVE` is defined before :file:`python.h` is included, a set of more aggressive optimizations are enabled for the module; you should benchmark the results to find out if these optimizations actually make the code faster. (Contributed by Fredrik Lundh at the NeedForSpeed sprint.) -* :cfunc:`PyErr_NewException(name, base, dict)` can now accept a tuple of base +* :c:func:`PyErr_NewException(name, base, dict)` can now accept a tuple of base classes as its *base* argument. (Contributed by Georg Brandl.) -* The :cfunc:`PyErr_Warn` function for issuing warnings is now deprecated in - favour of :cfunc:`PyErr_WarnEx(category, message, stacklevel)` which lets you +* The :c:func:`PyErr_Warn` function for issuing warnings is now deprecated in + favour of :c:func:`PyErr_WarnEx(category, message, stacklevel)` which lets you specify the number of stack frames separating this function and the caller. A - *stacklevel* of 1 is the function calling :cfunc:`PyErr_WarnEx`, 2 is the + *stacklevel* of 1 is the function calling :c:func:`PyErr_WarnEx`, 2 is the function above that, and so forth. (Added by Neal Norwitz.) * The CPython interpreter is still written in C, but the code can now be compiled with a C++ compiler without errors. (Implemented by Anthony Baxter, Martin von Löwis, Skip Montanaro.) -* The :cfunc:`PyRange_New` function was removed. It was never documented, never +* The :c:func:`PyRange_New` function was removed. It was never documented, never used in the core code, and had dangerously lax error checking. In the unlikely case that your extensions were using it, you can replace it by something like the following:: @@ -2203,7 +2203,7 @@ --------------------- * MacOS X (10.3 and higher): dynamic loading of modules now uses the - :cfunc:`dlopen` function instead of MacOS-specific functions. + :c:func:`dlopen` function instead of MacOS-specific functions. * MacOS X: an :option:`--enable-universalsdk` switch was added to the :program:`configure` script that compiles the interpreter as a universal binary @@ -2265,9 +2265,9 @@ earlier section :ref:`pep-353` for a discussion of this change. * C API: The obmalloc changes mean that you must be careful to not mix usage - of the :cfunc:`PyMem_\*` and :cfunc:`PyObject_\*` families of functions. Memory - allocated with one family's :cfunc:`\*_Malloc` must be freed with the - corresponding family's :cfunc:`\*_Free` function. + of the :c:func:`PyMem_\*` and :c:func:`PyObject_\*` families of functions. Memory + allocated with one family's :c:func:`\*_Malloc` must be freed with the + corresponding family's :c:func:`\*_Free` function. .. ====================================================================== ============================================================================== Revision: 5b3e66c2379b Author: cocoatomo <cocoa****@gmail*****> Date: Sat Dec 10 17:54:14 2011 Log: translate up to column identifier http://code.google.com/p/python-doc-ja/source/detail?r=5b3e66c2379b Modified: /library/ttk.rst ======================================= --- /library/ttk.rst Sat Dec 10 08:40:46 2011 +++ /library/ttk.rst Sat Dec 10 17:54:14 2011 @@ -676,7 +676,7 @@ データが表示される順序はウィジェットの ``displaycolumns`` オプションで制御 されます。 ツリーウィジェットはカラムヘッダを表示することもできます。 カラムには数字もしくはウィジェットの columns オプションにある名前でアクセス できます。 -`Column Identifiers`_ を参照してください。 +`カラム識別子`_ を参照してください。 それぞれの要素は一意な名前で識別されます。 要素の作成時に ID が与えられなかった場合、ウィジェットが要素の ID を生成し ます。 @@ -787,10 +787,10 @@ +------------+-----------------------------------------------------------+ -Column Identifiers -^^^^^^^^^^^^^^^^^^ - -Column identifiers take any of the following forms: +カラム識別子 +^^^^^^^^^^^^ + +カラム識別子は以下のいずれかの形式を取ります: * A symbolic name from the list of columns option. * An integer n, specifying the nth data column. ============================================================================== Revision: 4d8afa458e7b Author: cocoatomo <cocoa****@gmail*****> Date: Sat Dec 10 17:54:39 2011 Log: merge http://code.google.com/p/python-doc-ja/source/detail?r=4d8afa458e7b
