Merged revisions 74209 via svnmerge from

svn+ssh://pythondev@svn.python.org/python/trunk

........
  r74209 | georg.brandl | 2009-07-26 16:37:28 +0200 (So, 26 Jul 2009) | 1 line

  builtin -> built-in.
........

4 files changed, 10 insertions, 10 deletions

diff --git a/Doc/reference/datamodel.rst b/Doc/reference/datamodel.rst
index 5d612b8..865911f 100644
--- a/Doc/reference/datamodel.rst
+++ b/Doc/reference/datamodel.rst
@@ -1437,7 +1437,7 @@ Basic customization
 
    .. index:: builtin: unicode
 
-   Called to implement :func:`unicode` builtin; should return a Unicode object.
+   Called to implement :func:`unicode` built-in; should return a Unicode object.
    When this method is not defined, string conversion is attempted, and the result
    of string conversion is converted to Unicode using the system default encoding.
 
@@ -1516,7 +1516,7 @@ The following methods only apply to new-style classes.
    .. note::
 
       This method may still be bypassed when looking up special methods as the
-      result of implicit invocation via language syntax or builtin functions.
+      result of implicit invocation via language syntax or built-in functions.
       See :ref:`new-style-special-lookup`.
 
 
@@ -1865,12 +1865,12 @@ sequences, it should iterate through the values.
 
 .. method:: object.__reversed__(self)
 
-   Called (if present) by the :func:`reversed` builtin to implement
+   Called (if present) by the :func:`reversed` built-in to implement
    reverse iteration.  It should return a new iterator object that iterates
    over all the objects in the container in reverse order.
 
    If the :meth:`__reversed__` method is not provided, the :func:`reversed`
-   builtin will fall back to using the sequence protocol (:meth:`__len__` and
+   built-in will fall back to using the sequence protocol (:meth:`__len__` and
    :meth:`__getitem__`).  Objects that support the sequence protocol should
    only provide :meth:`__reversed__` if they can provide an implementation
    that is more efficient than the one provided by :func:`reversed`.
diff --git a/Doc/reference/executionmodel.rst b/Doc/reference/executionmodel.rst
index 9690a93..57a2205 100644
--- a/Doc/reference/executionmodel.rst
+++ b/Doc/reference/executionmodel.rst
@@ -112,9 +112,9 @@ determined by scanning the entire text of the block for name binding operations.
 If the global statement occurs within a block, all uses of the name specified in
 the statement refer to the binding of that name in the top-level namespace.
 Names are resolved in the top-level namespace by searching the global namespace,
-i.e. the namespace of the module containing the code block, and the builtin
+i.e. the namespace of the module containing the code block, and the builtins
 namespace, the namespace of the module :mod:`__builtin__`.  The global namespace
-is searched first.  If the name is not found there, the builtin namespace is
+is searched first.  If the name is not found there, the builtins namespace is
 searched.  The global statement must precede all uses of the name.
 
 .. index:: pair: restricted; execution
diff --git a/Doc/reference/expressions.rst b/Doc/reference/expressions.rst
index 0af8ee1..e1b0ada 100644
--- a/Doc/reference/expressions.rst
+++ b/Doc/reference/expressions.rst
@@ -665,7 +665,7 @@ the call.
 
 .. note::
 
-   An implementation may provide builtin functions whose positional parameters do
+   An implementation may provide built-in functions whose positional parameters do
    not have names, even if they are 'named' for the purpose of documentation, and
    which therefore cannot be supplied by keyword.  In CPython, this is the case for
    functions implemented in C that use :cfunc:`PyArg_ParseTuple` to parse their
@@ -1032,7 +1032,7 @@ The operators ``<``, ``>``, ``==``, ``>=``, ``<=``, and ``!=`` compare the
 values of two objects.  The objects need not have the same type. If both are
 numbers, they are converted to a common type.  Otherwise, objects of different
 types *always* compare unequal, and are ordered consistently but arbitrarily.
-You can control comparison behavior of objects of non-builtin types by defining
+You can control comparison behavior of objects of non-built-in types by defining
 a ``__cmp__`` method or rich comparison methods like ``__gt__``, described in
 section :ref:`specialnames`.
 
@@ -1063,7 +1063,7 @@ Comparison of objects of the same type depends on the type:
   lists compare equal. [#]_ Outcomes other than equality are resolved
   consistently, but are not otherwise defined. [#]_
 
-* Most other objects of builtin types compare unequal unless they are the same
+* Most other objects of built-in types compare unequal unless they are the same
   object; the choice whether one object is considered smaller or larger than
   another one is made arbitrarily but consistently within one execution of a
   program.
diff --git a/Doc/reference/simple_stmts.rst b/Doc/reference/simple_stmts.rst
index 0e8ba67..1c7ce71 100644
--- a/Doc/reference/simple_stmts.rst
+++ b/Doc/reference/simple_stmts.rst
@@ -895,7 +895,7 @@ Note that there is nothing special about the statement::
 That is not a future statement; it's an ordinary import statement with no
 special semantics or syntax restrictions.
 
-Code compiled by an :keyword:`exec` statement or calls to the builtin functions
+Code compiled by an :keyword:`exec` statement or calls to the built-in functions
 :func:`compile` and :func:`execfile` that occur in a module :mod:`M` containing
 a future statement will, by default, use the new  syntax or semantics associated
 with the future statement.  This can, starting with Python 2.2 be controlled by