builtin -> built-in.

43 files changed, 82 insertions, 83 deletions

diff --git a/Doc/c-api/buffer.rst b/Doc/c-api/buffer.rst
index 3f13e74084..48243582ae 100644
--- a/Doc/c-api/buffer.rst
+++ b/Doc/c-api/buffer.rst
@@ -31,7 +31,7 @@ interface can be written to a file. There are a number of format codes to
 returning data from the target object.
 
 Starting from version 1.6, Python has been providing Python-level buffer
-objects and a C-level buffer API so that any builtin or used-defined type can
+objects and a C-level buffer API so that any built-in or used-defined type can
 expose its characteristics. Both, however, have been deprecated because of
 various shortcomings, and have been officially removed in Python 3.0 in favour
 of a new C-level buffer API and a new Python-level object named
diff --git a/Doc/c-api/import.rst b/Doc/c-api/import.rst
index 581d396310..2025ba1ed8 100644
--- a/Doc/c-api/import.rst
+++ b/Doc/c-api/import.rst
@@ -167,7 +167,7 @@ Importing Modules
    *path*, possibly by fetching it from the :data:`sys.path_importer_cache`
    dict.  If it wasn't yet cached, traverse :data:`sys.path_hooks` until a hook
    is found that can handle the path item.  Return ``None`` if no hook could;
-   this tells our caller it should fall back to the builtin import mechanism.
+   this tells our caller it should fall back to the built-in import mechanism.
    Cache the result in :data:`sys.path_importer_cache`.  Return a new reference
    to the importer object.
 
diff --git a/Doc/c-api/unicode.rst b/Doc/c-api/unicode.rst
index b603734648..1249ed725f 100644
--- a/Doc/c-api/unicode.rst
+++ b/Doc/c-api/unicode.rst
@@ -292,12 +292,12 @@ the system's :ctype:`wchar_t`.
 Built-in Codecs
 ^^^^^^^^^^^^^^^
 
-Python provides a set of builtin codecs which are written in C for speed. All of
+Python provides a set of built-in codecs which are written in C for speed. All of
 these codecs are directly usable via the following functions.
 
 Many of the following APIs take two arguments encoding and errors. These
 parameters encoding and errors have the same semantics as the ones of the
-builtin unicode() Unicode object constructor.
+built-in :func:`unicode` Unicode object constructor.
 
 Setting encoding to *NULL* causes the default encoding to be used which is
 ASCII.  The file system calls should use :cdata:`Py_FileSystemDefaultEncoding`
@@ -307,7 +307,7 @@ at run-time (such as when the application invokes setlocale).
 
 Error handling is set by errors which may also be set to *NULL* meaning to use
 the default handling defined for the codec.  Default error handling for all
-builtin codecs is "strict" (:exc:`ValueError` is raised).
+built-in codecs is "strict" (:exc:`ValueError` is raised).
 
 The codecs all use a similar interface.  Only deviation from the following
 generic ones are documented for simplicity.
@@ -321,7 +321,7 @@ These are the generic codec APIs:
 
    Create a Unicode object by decoding *size* bytes of the encoded string *s*.
    *encoding* and *errors* have the same meaning as the parameters of the same name
-   in the :func:`unicode` builtin function.  The codec to be used is looked up
+   in the :func:`unicode` built-in function.  The codec to be used is looked up
    using the Python codec registry.  Return *NULL* if an exception was raised by
    the codec.
 
diff --git a/Doc/distutils/apiref.rst b/Doc/distutils/apiref.rst
index fa28516167..f0408e8ab1 100644
--- a/Doc/distutils/apiref.rst
+++ b/Doc/distutils/apiref.rst
@@ -1601,7 +1601,7 @@ lines, and joining lines with backslashes.
    +------------------+--------------------------------+---------+
 
    Note that since *rstrip_ws* can strip the trailing newline, the semantics of
-   :meth:`readline` must differ from those of the builtin file object's
+   :meth:`readline` must differ from those of the built-in file object's
    :meth:`readline` method!  In particular, :meth:`readline`  returns ``None`` for
    end-of-file: an empty string might just be a  blank line (or an all-whitespace
    line), if *rstrip_ws* is true  but *skip_blanks* is not.
@@ -1609,8 +1609,8 @@ lines, and joining lines with backslashes.
 
    .. method:: TextFile.open(filename)
 
-      Open a new file *filename*. This overrides any *file* or  *filename* constructor
-      arguments.
+      Open a new file *filename*.  This overrides any *file* or *filename*
+      constructor arguments.
 
 
    .. method:: TextFile.close()
diff --git a/Doc/extending/newtypes.rst b/Doc/extending/newtypes.rst
index 030de57f77..e3cf66a2da 100644
--- a/Doc/extending/newtypes.rst
+++ b/Doc/extending/newtypes.rst
@@ -819,7 +819,7 @@ easily use the :class:`PyTypeObject` it needs. It can be difficult to share
 these :class:`PyTypeObject` structures between extension modules.
 
 In this example we will create a :class:`Shoddy` type that inherits from the
-builtin :class:`list` type. The new type will be completely compatible with
+built-in :class:`list` type. The new type will be completely compatible with
 regular lists, but will have an additional :meth:`increment` method that
 increases an internal counter. ::
 
diff --git a/Doc/glossary.rst b/Doc/glossary.rst
index 87a77d07d5..f7689afaff 100644
--- a/Doc/glossary.rst
+++ b/Doc/glossary.rst
@@ -28,11 +28,11 @@ Glossary
 
    abstract base class
       Abstract Base Classes (abbreviated ABCs) complement :term:`duck-typing` by
-      providing a way to define interfaces when other techniques like :func:`hasattr`
-      would be clumsy. Python comes with many builtin ABCs for data structures
-      (in the :mod:`collections` module), numbers (in the :mod:`numbers`
-      module), and streams (in the :mod:`io` module). You can create your own
-      ABC with the :mod:`abc` module.
+      providing a way to define interfaces when other techniques like
+      :func:`hasattr` would be clumsy. Python comes with many built-in ABCs for
+      data structures (in the :mod:`collections` module), numbers (in the
+      :mod:`numbers` module), and streams (in the :mod:`io` module). You can
+      create your own ABC with the :mod:`abc` module.
 
    argument
       A value passed to a function or method, assigned to a named local
@@ -79,7 +79,7 @@ Glossary
       in ``3+4.5``, each argument is of a different type (one int, one float),
       and both must be converted to the same type before they can be added or it
       will raise a ``TypeError``.  Coercion between two operands can be
-      performed with the ``coerce`` builtin function; thus, ``3+4.5`` is
+      performed with the ``coerce`` built-in function; thus, ``3+4.5`` is
       equivalent to calling ``operator.add(*coerce(3, 4.5))`` and results in
       ``operator.add(3.0, 4.5)``.  Without coercion, all arguments of even
       compatible types would have to be normalized to the same value by the
@@ -90,7 +90,7 @@ Glossary
       expressed as a sum of a real part and an imaginary part.  Imaginary
       numbers are real multiples of the imaginary unit (the square root of
       ``-1``), often written ``i`` in mathematics or ``j`` in
-      engineering. Python has builtin support for complex numbers, which are
+      engineering.  Python has built-in support for complex numbers, which are
       written with this latter notation; the imaginary part is written with a
       ``j`` suffix, e.g., ``3+1j``.  To get access to complex equivalents of the
       :mod:`math` module, use :mod:`cmath`.  Use of complex numbers is a fairly
@@ -322,7 +322,7 @@ Glossary
       define with an :meth:`__iter__` or :meth:`__getitem__` method.  Iterables
       can be used in a :keyword:`for` loop and in many other places where a
       sequence is needed (:func:`zip`, :func:`map`, ...).  When an iterable
-      object is passed as an argument to the builtin function :func:`iter`, it
+      object is passed as an argument to the built-in function :func:`iter`, it
       returns an iterator for the object.  This iterator is good for one pass
       over the set of values.  When using iterables, it is usually not necessary
       to call :func:`iter` or deal with iterator objects yourself.  The ``for``
@@ -424,7 +424,7 @@ Glossary
 
    namespace
       The place where a variable is stored.  Namespaces are implemented as
-      dictionaries.  There are the local, global and builtin namespaces as well
+      dictionaries.  There are the local, global and built-in namespaces as well
       as nested namespaces in objects (in methods).  Namespaces support
       modularity by preventing naming conflicts.  For instance, the functions
       :func:`__builtin__.open` and :func:`os.open` are distinguished by their
diff --git a/Doc/howto/doanddont.rst b/Doc/howto/doanddont.rst
index eee576596f..f795eadb46 100644
--- a/Doc/howto/doanddont.rst
+++ b/Doc/howto/doanddont.rst
@@ -261,7 +261,7 @@ Compare::
 More useful functions in :mod:`os.path`: :func:`basename`,  :func:`dirname` and
 :func:`splitext`.
 
-There are also many useful builtin functions people seem not to be aware of for
+There are also many useful built-in functions people seem not to be aware of for
 some reason: :func:`min` and :func:`max` can find the minimum/maximum of any
 sequence with comparable semantics, for example, yet many people write their own
 :func:`max`/:func:`min`. Another highly useful function is :func:`reduce`. A
diff --git a/Doc/howto/urllib2.rst b/Doc/howto/urllib2.rst
index 409bc8ea29..e10a5a4ffa 100644
--- a/Doc/howto/urllib2.rst
+++ b/Doc/howto/urllib2.rst
@@ -182,10 +182,9 @@ which comes after we have a look at what happens when things go wrong.
 Handling Exceptions
 ===================
 
-*urlopen* raises :exc:`URLError` when it cannot handle a response (though as usual
-with Python APIs, builtin exceptions such as
-:exc:`ValueError`, :exc:`TypeError` etc. may also
-be raised).
+*urlopen* raises :exc:`URLError` when it cannot handle a response (though as
+usual with Python APIs, built-in exceptions such as :exc:`ValueError`,
+:exc:`TypeError` etc. may also be raised).
 
 :exc:`HTTPError` is the subclass of :exc:`URLError` raised in the specific case of
 HTTP URLs.
diff --git a/Doc/includes/sqlite3/text_factory.py b/Doc/includes/sqlite3/text_factory.py
index 94a59da4b7..195949866f 100644
--- a/Doc/includes/sqlite3/text_factory.py
+++ b/Doc/includes/sqlite3/text_factory.py
@@ -31,7 +31,7 @@ cur.execute("select ?", ("this is latin1 and would normally create errors" +
 row = cur.fetchone()
 assert type(row[0]) == unicode
 
-# sqlite3 offers a builtin optimized text_factory that will return bytestring
+# sqlite3 offers a built-in optimized text_factory that will return bytestring
 # objects, if the data is in ASCII only, and otherwise return unicode objects
 con.text_factory = sqlite3.OptimizedUnicode
 cur.execute("select ?", (AUSTRIA,))
diff --git a/Doc/library/2to3.rst b/Doc/library/2to3.rst
index a87a29cc9b..f37bb05565 100644
--- a/Doc/library/2to3.rst
+++ b/Doc/library/2to3.rst
@@ -209,7 +209,7 @@ and off individually.  They are described here in more detail.
 .. 2to3fixer:: itertools
 
    Changes usage of :func:`itertools.ifilter`, :func:`itertools.izip`, and
-   :func:`itertools.imap` to their builtin equivalents.
+   :func:`itertools.imap` to their built-in equivalents.
    :func:`itertools.ifilterfalse` is changed to :func:`itertools.filterfalse`.
 
 .. 2to3fixer:: long
diff --git a/Doc/library/__future__.rst b/Doc/library/__future__.rst
index b09246ef09..29f3109426 100644
--- a/Doc/library/__future__.rst
+++ b/Doc/library/__future__.rst
@@ -52,7 +52,7 @@ Instances of class :class:`_Feature` have two corresponding methods,
 :meth:`getOptionalRelease` and :meth:`getMandatoryRelease`.
 
 *CompilerFlag* is the (bitfield) flag that should be passed in the fourth
-argument to the builtin function :func:`compile` to enable the feature in
+argument to the built-in function :func:`compile` to enable the feature in
 dynamically compiled code.  This flag is stored in the :attr:`compiler_flag`
 attribute on :class:`_Feature` instances.
 
diff --git a/Doc/library/_winreg.rst b/Doc/library/_winreg.rst
index 7876f8573b..c003fe2c10 100644
--- a/Doc/library/_winreg.rst
+++ b/Doc/library/_winreg.rst
@@ -408,7 +408,7 @@ detached).
 The object also support comparison semantics, so handle objects will compare
 true if they both reference the same underlying Windows handle value.
 
-Handle objects can be converted to an integer (e.g., using the builtin
+Handle objects can be converted to an integer (e.g., using the built-in
 :func:`int` function), in which case the underlying Windows handle value is
 returned.  You can also use the  :meth:`Detach` method to return the integer
 handle, and also disconnect the Windows handle from the handle object.
diff --git a/Doc/library/ast.rst b/Doc/library/ast.rst
index 5c1d5c45d0..82ca6e35c1 100644
--- a/Doc/library/ast.rst
+++ b/Doc/library/ast.rst
@@ -22,7 +22,7 @@ Python release; this module helps to find out programmatically what the current
 grammar looks like.
 
 An abstract syntax tree can be generated by passing :data:`ast.PyCF_ONLY_AST` as
-a flag to the :func:`compile` builtin function, or using the :func:`parse`
+a flag to the :func:`compile` built-in function, or using the :func:`parse`
 helper provided in this module.  The result will be a tree of objects whose
 classes all inherit from :class:`ast.AST`.  An abstract syntax tree can be
 compiled into a Python code object using the built-in :func:`compile` function.
diff --git a/Doc/library/collections.rst b/Doc/library/collections.rst
index 1ecd17ab7c..c0d539f658 100644
--- a/Doc/library/collections.rst
+++ b/Doc/library/collections.rst
@@ -509,7 +509,7 @@ stack manipulations such as ``dup``, ``drop``, ``swap``, ``over``, ``pick``,
 .. class:: defaultdict([default_factory[, ...]])
 
    Returns a new dictionary-like object.  :class:`defaultdict` is a subclass of the
-   builtin :class:`dict` class.  It overrides one method and adds one writable
+   built-in :class:`dict` class.  It overrides one method and adds one writable
    instance variable.  The remaining functionality is the same as for the
    :class:`dict` class and is not documented here.
 
diff --git a/Doc/library/compiler.rst b/Doc/library/compiler.rst
index 0093518d50..991628ae52 100644
--- a/Doc/library/compiler.rst
+++ b/Doc/library/compiler.rst
@@ -21,11 +21,11 @@ Python.  It uses the built-in parser and standard :mod:`parser` module to
 generated a concrete syntax tree.  This tree is used to generate an abstract
 syntax tree (AST) and then Python bytecode.
 
-The full functionality of the package duplicates the builtin compiler provided
+The full functionality of the package duplicates the built-in compiler provided
 with the Python interpreter.  It is intended to match its behavior almost
 exactly.  Why implement another compiler that does the same thing?  The package
 is useful for a variety of purposes.  It can be modified more easily than the
-builtin compiler.  The AST it generates is useful for analyzing Python source
+built-in compiler.  The AST it generates is useful for analyzing Python source
 code.
 
 This chapter explains how the various components of the :mod:`compiler` package
@@ -118,7 +118,7 @@ for a construct, there are often several levels of nested nodes that are
 introduced by Python's precedence rules.
 
 The abstract syntax tree is created by the :mod:`compiler.transformer` module.
-The transformer relies on the builtin Python parser to generate a concrete
+The transformer relies on the built-in Python parser to generate a concrete
 syntax tree.  It generates an abstract syntax tree from the concrete tree.
 
 .. index::
diff --git a/Doc/library/configparser.rst b/Doc/library/configparser.rst
index 2eeefb0cd6..ef27524ba2 100644
--- a/Doc/library/configparser.rst
+++ b/Doc/library/configparser.rst
@@ -56,7 +56,7 @@ Default values can be specified by passing them into the :class:`ConfigParser`
 constructor as a dictionary.  Additional defaults  may be passed into the
 :meth:`get` method which will override all others.
 
-Sections are normally stored in a builtin dictionary. An alternative dictionary
+Sections are normally stored in a built-in dictionary. An alternative dictionary
 type can be passed to the :class:`ConfigParser` constructor. For example, if a
 dictionary type is passed that sorts its keys, the sections will be sorted on
 write-back, as will be the keys within each section.
diff --git a/Doc/library/curses.rst b/Doc/library/curses.rst
index c53b10559c..fa66d1efa1 100644
--- a/Doc/library/curses.rst
+++ b/Doc/library/curses.rst
@@ -609,9 +609,9 @@ the following methods:
    .. note::
 
       A *character* means a C character (an ASCII code), rather then a Python
-      character (a string of length 1). (This note is true whenever the documentation
-      mentions a character.) The builtin :func:`ord` is handy for conveying strings to
-      codes.
+      character (a string of length 1). (This note is true whenever the
+      documentation mentions a character.) The built-in :func:`ord` is handy for
+      conveying strings to codes.
 
    Paint character *ch* at ``(y, x)`` with attributes *attr*, overwriting any
    character previously painter at that location.  By default, the character
diff --git a/Doc/library/functions.rst b/Doc/library/functions.rst
index 1ae00d53ac..5fd811406c 100644
--- a/Doc/library/functions.rst
+++ b/Doc/library/functions.rst
@@ -847,7 +847,7 @@ available.  They are listed here in alphabetical order.
 
    .. note::
 
-      This function is not normally available as a builtin since the name
+      This function is not normally available as a built-in since the name
       ``print`` is recognized as the :keyword:`print` statement.  To disable the
       statement and use the :func:`print` function, use this future statement at
       the top of your module::
diff --git a/Doc/library/future_builtins.rst b/Doc/library/future_builtins.rst
index 7ee7110f63..16e7d4bcf1 100644
--- a/Doc/library/future_builtins.rst
+++ b/Doc/library/future_builtins.rst
@@ -1,14 +1,14 @@
-:mod:`future_builtins` --- Python 3 builtins
-============================================
+:mod:`future_builtins` --- Python 3 built-ins
+=============================================
 
 .. module:: future_builtins
 .. sectionauthor:: Georg Brandl
 .. versionadded:: 2.6
 
 This module provides functions that exist in 2.x, but have different behavior in
-Python 3, so they cannot be put into the 2.x builtin namespace.
+Python 3, so they cannot be put into the 2.x builtins namespace.
 
-Instead, if you want to write code compatible with Python 3 builtins, import
+Instead, if you want to write code compatible with Python 3 built-ins, import
 them from this module, like this::
 
    from future_builtins import map, filter
@@ -16,17 +16,17 @@ them from this module, like this::
    ... code using Python 3-style map and filter ...
 
 The :term:`2to3` tool that ports Python 2 code to Python 3 will recognize
-this usage and leave the new builtins alone.
+this usage and leave the new built-ins alone.
 
 .. note::
 
-   The Python 3 :func:`print` function is already in the builtins, but cannot be
+   The Python 3 :func:`print` function is already in the built-ins, but cannot be
    accessed from Python 2 code unless you use the appropriate future statement::
 
       from __future__ import print_function
 
 
-Available builtins are:
+Available built-ins are:
 
 .. function:: ascii(object)
 
@@ -42,7 +42,7 @@ Available builtins are:
 
 .. function:: hex(object)
 
-   Works like the builtin :func:`hex`, but instead of :meth:`__hex__` it will
+   Works like the built-in :func:`hex`, but instead of :meth:`__hex__` it will
    use the :meth:`__index__` method on its argument to get an integer that is
    then converted to hexadecimal.
 
@@ -52,7 +52,7 @@ Available builtins are:
 
 .. function:: oct(object)
 
-   Works like the builtin :func:`oct`, but instead of :meth:`__oct__` it will
+   Works like the built-in :func:`oct`, but instead of :meth:`__oct__` it will
    use the :meth:`__index__` method on its argument to get an integer that is
    then converted to octal.
 
diff --git a/Doc/library/gc.rst b/Doc/library/gc.rst
index 65f0f39a15..80a2d925ce 100644
--- a/Doc/library/gc.rst
+++ b/Doc/library/gc.rst
@@ -48,7 +48,7 @@ The :mod:`gc` module provides the following functions:
       The optional *generation* argument was added.
 
    .. versionchanged:: 2.6
-      The free lists maintained for a number of builtin types are cleared
+      The free lists maintained for a number of built-in types are cleared
       whenever a full collection or collection of the highest generation (2)
       is run.  Not all items in some free lists may be freed due to the
       particular implementation, in particular :class:`int` and :class:`float`.
diff --git a/Doc/library/gettext.rst b/Doc/library/gettext.rst
index b95eb7910f..405a3820af 100644
--- a/Doc/library/gettext.rst
+++ b/Doc/library/gettext.rst
@@ -205,7 +205,7 @@ the built-in namespace as the function :func:`_`.
 
 .. function:: install(domain[, localedir[, unicode [, codeset[, names]]]])
 
-   This installs the function :func:`_` in Python's builtin namespace, based on
+   This installs the function :func:`_` in Python's builtins namespace, based on
    *domain*, *localedir*, and *codeset* which are passed to the function
    :func:`translation`.  The *unicode* flag is passed to the resulting translation
    object's :meth:`install` method.
@@ -220,7 +220,7 @@ the built-in namespace as the function :func:`_`.
       print _('This string will be translated.')
 
    For convenience, you want the :func:`_` function to be installed in Python's
-   builtin namespace, so it is easily accessible in all modules of your
+   builtins namespace, so it is easily accessible in all modules of your
    application.
 
    .. versionchanged:: 2.4
@@ -347,7 +347,7 @@ are the methods of :class:`NullTranslations`:
       it binds :meth:`self.ugettext` instead.  By default, *unicode* is false.
 
       If the *names* parameter is given, it must be a sequence containing the
-      names of functions you want to install in the builtin namespace in
+      names of functions you want to install in the builtins namespace in
       addition to :func:`_`.  Supported names are ``'gettext'`` (bound to
       :meth:`self.gettext` or :meth:`self.ugettext` according to the *unicode*
       flag), ``'ngettext'`` (bound to :meth:`self.ngettext` or
diff --git a/Doc/library/heapq.rst b/Doc/library/heapq.rst
index bf7e3c4cd2..9a44047d0e 100644
--- a/Doc/library/heapq.rst
+++ b/Doc/library/heapq.rst
@@ -147,7 +147,7 @@ The module also offers three general purpose functions based on heaps.
 
 The latter two functions perform best for smaller values of *n*.  For larger
 values, it is more efficient to use the :func:`sorted` function.  Also, when
-``n==1``, it is more efficient to use the builtin :func:`min` and :func:`max`
+``n==1``, it is more efficient to use the built-in :func:`min` and :func:`max`
 functions.
 
 
diff --git a/Doc/library/imputil.rst b/Doc/library/imputil.rst
index 86089d241f..94194e2f72 100644
--- a/Doc/library/imputil.rst
+++ b/Doc/library/imputil.rst
@@ -79,7 +79,7 @@ approach to custom :keyword:`import` functions.
 
 .. class:: BuiltinImporter()
 
-   Emulate the import mechanism for builtin and frozen modules.  This is a
+   Emulate the import mechanism for built-in and frozen modules.  This is a
    sub-class of the :class:`Importer` class.
 
    .. method:: BuiltinImporter.get_code(parent, modname, fqname)
diff --git a/Doc/library/io.rst b/Doc/library/io.rst
index 184e443057..3dba0b5e99 100644
--- a/Doc/library/io.rst
+++ b/Doc/library/io.rst
@@ -10,7 +10,7 @@
 .. versionadded:: 2.6
 
 The :mod:`io` module provides the Python interfaces to stream handling.  The
-builtin :func:`open` function is defined in this module.
+built-in :func:`open` function is defined in this module.
 
 At the top of the I/O hierarchy is the abstract base class :class:`IOBase`.  It
 defines the basic interface to a stream.  Note, however, that there is no
diff --git a/Doc/library/multiprocessing.rst b/Doc/library/multiprocessing.rst
index 9522865bf9..9e53aa5635 100644
--- a/Doc/library/multiprocessing.rst
+++ b/Doc/library/multiprocessing.rst
@@ -1555,8 +1555,8 @@ with the :class:`Pool` class.
 
    .. method:: apply(func[, args[, kwds]])
 
-      Equivalent of the :func:`apply` builtin function.  It blocks till the
-      result is ready. Given this blocks - :meth:`apply_async` is better suited
+      Equivalent of the :func:`apply` built-in function.  It blocks till the
+      result is ready.  Given this blocks, :meth:`apply_async` is better suited
       for performing work in parallel. Additionally, the passed
       in function is only executed in one of the workers of the pool.
 
@@ -1571,7 +1571,7 @@ with the :class:`Pool` class.
 
    .. method:: map(func, iterable[, chunksize])
 
-      A parallel equivalent of the :func:`map` builtin function (it supports only
+      A parallel equivalent of the :func:`map` built-in function (it supports only
       one *iterable* argument though).  It blocks till the result is ready.
 
       This method chops the iterable into a number of chunks which it submits to
diff --git a/Doc/library/numbers.rst b/Doc/library/numbers.rst
index b0d55a7406..580127c095 100644
--- a/Doc/library/numbers.rst
+++ b/Doc/library/numbers.rst
@@ -24,7 +24,7 @@ The numeric tower
 .. class:: Complex
 
    Subclasses of this type describe complex numbers and include the operations
-   that work on the builtin :class:`complex` type. These are: conversions to
+   that work on the built-in :class:`complex` type. These are: conversions to
    :class:`complex` and :class:`bool`, :attr:`.real`, :attr:`.imag`, ``+``,
    ``-``, ``*``, ``/``, :func:`abs`, :meth:`conjugate`, ``==``, and ``!=``. All
    except ``-`` and ``!=`` are abstract.
diff --git a/Doc/library/pprint.rst b/Doc/library/pprint.rst
index 7bcb3f1856..36a2bc489f 100644
--- a/Doc/library/pprint.rst
+++ b/Doc/library/pprint.rst
@@ -13,7 +13,7 @@ Python data structures in a form which can be used as input to the interpreter.
 If the formatted structures include objects which are not fundamental Python
 types, the representation may not be loadable.  This may be the case if objects
 such as files, sockets, classes, or instances are included, as well as many
-other builtin objects which are not representable as Python constants.
+other built-in objects which are not representable as Python constants.
 
 The formatted representation keeps objects on a single line if it can, and
 breaks them onto multiple lines if they don't fit within the allowed width.
diff --git a/Doc/library/sets.rst b/Doc/library/sets.rst
index 6d974d6ef7..47b2d76928 100644
--- a/Doc/library/sets.rst
+++ b/Doc/library/sets.rst
@@ -184,7 +184,7 @@ any iterable as an argument.
 Also note, the module also includes a :meth:`union_update` method which is an
 alias for :meth:`update`.  The method is included for backwards compatibility.
 Programmers should prefer the :meth:`update` method because it is supported by
-the builtin :class:`set()` and :class:`frozenset()` types.
+the built-in :class:`set()` and :class:`frozenset()` types.
 
 
 .. _set-example:
diff --git a/Doc/library/sqlite3.rst b/Doc/library/sqlite3.rst
index 392a130abf..d437028bab 100644
--- a/Doc/library/sqlite3.rst
+++ b/Doc/library/sqlite3.rst
@@ -840,7 +840,7 @@ directly using only a single call on the :class:`Connection` object.
 Accessing columns by name instead of by index
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-One useful feature of the :mod:`sqlite3` module is the builtin
+One useful feature of the :mod:`sqlite3` module is the built-in
 :class:`sqlite3.Row` class designed to be used as a row factory.
 
 Rows wrapped with this class can be accessed both by index (like tuples) and
diff --git a/Doc/library/stdtypes.rst b/Doc/library/stdtypes.rst
index 2e47c59bb6..091cae4a10 100644
--- a/Doc/library/stdtypes.rst
+++ b/Doc/library/stdtypes.rst
@@ -277,7 +277,7 @@ numbers of mixed type use the same rule. [#]_ The constructors :func:`int`,
 :func:`long`, :func:`float`, and :func:`complex` can be used to produce numbers
 of a specific type.
 
-All builtin numeric types support the following operations. See
+All built-in numeric types support the following operations. See
 :ref:`power` and later sections for the operators' priorities.
 
 +--------------------+---------------------------------+--------+
@@ -675,7 +675,7 @@ must have the enclosing parentheses, such as ``a, b, c`` or ``()``.  A
 single item tuple must have a trailing comma, such as ``(d,)``.
 
 Buffer objects are not directly supported by Python syntax, but can be created
-by calling the builtin function :func:`buffer`.  They don't support
+by calling the built-in function :func:`buffer`.  They don't support
 concatenation or repetition.
 
 Objects of type xrange are similar to buffers in that there is no specific syntax to
@@ -1632,7 +1632,7 @@ set``.  Being an unordered collection, sets do not record element position or
 order of insertion.  Accordingly, sets do not support indexing, slicing, or
 other sequence-like behavior.
 
-There are currently two builtin set types, :class:`set` and :class:`frozenset`.
+There are currently two built-in set types, :class:`set` and :class:`frozenset`.
 The :class:`set` type is mutable --- the contents can be changed using methods
 like :meth:`add` and :meth:`remove`.  Since it is mutable, it has no hash value
 and cannot be used as either a dictionary key or as an element of another set.
diff --git a/Doc/library/string.rst b/Doc/library/string.rst
index 3231d131e8..0b9b1fb31a 100644
--- a/Doc/library/string.rst
+++ b/Doc/library/string.rst
@@ -312,7 +312,7 @@ Format Specification Mini-Language
 
 "Format specifications" are used within replacement fields contained within a
 format string to define how individual values are presented (see
-:ref:`formatstrings`.)  They can also be passed directly to the builtin
+:ref:`formatstrings`.)  They can also be passed directly to the built-in
 :func:`format` function.  Each formattable type may define how the format
 specification is to be interpreted.
 
diff --git a/Doc/library/sys.rst b/Doc/library/sys.rst
index 8616d5d657..0005792774 100644
--- a/Doc/library/sys.rst
+++ b/Doc/library/sys.rst
@@ -816,7 +816,7 @@ always available.
 
    ``'c_call'``
       A C function is about to be called.  This may be an extension function or
-      a builtin.  *arg* is the C function object.
+      a built-in.  *arg* is the C function object.
 
    ``'c_return'``
       A C function has returned. *arg* is ``None``.
diff --git a/Doc/library/undoc.rst b/Doc/library/undoc.rst
index f62c96a722..b8b66c6925 100644
--- a/Doc/library/undoc.rst
+++ b/Doc/library/undoc.rst
@@ -113,7 +113,7 @@ BuildApplication to combine all plugin modules to a single executable.
    :deprecated:
 
 
-Importing :mod:`icopen` will replace the builtin :meth:`open` with a version
+Importing :mod:`icopen` will replace the built-in :meth:`open` with a version
 that uses Internet Config to set file type and creator for new files.
 
 .. deprecated:: 2.6
diff --git a/Doc/library/weakref.rst b/Doc/library/weakref.rst
index 2ca864fc1d..5dcb03029f 100644
--- a/Doc/library/weakref.rst
+++ b/Doc/library/weakref.rst
@@ -65,7 +65,7 @@ and regular expression pattern objects.
 .. versionchanged:: 2.4
    Added support for files, sockets, arrays, and patterns.
 
-Several builtin types such as :class:`list` and :class:`dict` do not directly
+Several built-in types such as :class:`list` and :class:`dict` do not directly
 support weak references but can add support through subclassing::
 
    class Dict(dict):
diff --git a/Doc/library/xmlrpclib.rst b/Doc/library/xmlrpclib.rst
index 647cda9b9f..ee99950f07 100644
--- a/Doc/library/xmlrpclib.rst
+++ b/Doc/library/xmlrpclib.rst
@@ -94,7 +94,7 @@ between conformable Python objects and XML on the wire.
    :exc:`ProtocolError` used to signal an error in the HTTP/HTTPS transport layer.
    Both :exc:`Fault` and :exc:`ProtocolError` derive from a base class called
    :exc:`Error`.  Note that even though starting with Python 2.2 you can subclass
-   builtin types, the xmlrpclib module currently does not marshal instances of such
+   built-in types, the xmlrpclib module currently does not marshal instances of such
    subclasses.
 
    When passing strings, characters special to XML such as ``<``, ``>``, and ``&``
diff --git a/Doc/library/zipimport.rst b/Doc/library/zipimport.rst
index d659efe55a..791aba4f72 100644
--- a/Doc/library/zipimport.rst
+++ b/Doc/library/zipimport.rst
@@ -12,7 +12,7 @@
 This module adds the ability to import Python modules (:file:`\*.py`,
 :file:`\*.py[co]`) and packages from ZIP-format archives. It is usually not
 needed to use the :mod:`zipimport` module explicitly; it is automatically used
-by the builtin :keyword:`import` mechanism for ``sys.path`` items that are paths
+by the built-in :keyword:`import` mechanism for ``sys.path`` items that are paths
 to ZIP archives.
 
 Typically, ``sys.path`` is a list of directory names as strings.  This module
diff --git a/Doc/reference/datamodel.rst b/Doc/reference/datamodel.rst
index 5d612b814e..865911ffe2 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 9690a9391b..57a2205134 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 0af8ee1db0..e1b0ada60a 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 6f0f1f12eb..b92628329c 100644
--- a/Doc/reference/simple_stmts.rst
+++ b/Doc/reference/simple_stmts.rst
@@ -891,7 +891,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
diff --git a/Doc/using/cmdline.rst b/Doc/using/cmdline.rst
index 3c482a1354..1762ddc0c0 100644
--- a/Doc/using/cmdline.rst
+++ b/Doc/using/cmdline.rst
@@ -86,7 +86,7 @@ source.
 
    .. note::
 
-      This option cannot be used with builtin modules and extension modules
+      This option cannot be used with built-in modules and extension modules
       written in C, since they do not have Python module files. However, it
       can still be used for precompiled modules, even if the original source
       file is not available.
diff --git a/Doc/whatsnew/2.2.rst b/Doc/whatsnew/2.2.rst
index ec435f71ba..acdba831f0 100644
--- a/Doc/whatsnew/2.2.rst
+++ b/Doc/whatsnew/2.2.rst
@@ -1173,7 +1173,7 @@ Some of the more notable changes are:
      can uncomment them. Gestalt and Internet Config modules are enabled by
      default.
 
-* Keyword arguments passed to builtin functions that don't take them now cause a
+* Keyword arguments passed to built-in functions that don't take them now cause a
   :exc:`TypeError` exception to be raised, with the message "*function* takes no
   keyword arguments".
 
diff --git a/Doc/whatsnew/2.6.rst b/Doc/whatsnew/2.6.rst
index fb2f6fee89..a629e5f26c 100644
--- a/Doc/whatsnew/2.6.rst
+++ b/Doc/whatsnew/2.6.rst
@@ -2819,7 +2819,7 @@ JSON (Javascript Object Notation). JSON is a lightweight interchange format
 often used in web applications. For more information about JSON, see
 http://www.json.org.
 
-:mod:`json` comes with support for decoding and encoding most builtin Python
+:mod:`json` comes with support for decoding and encoding most built-in Python
 types. The following example encodes and decodes a dictionary::
 
        >>> import json