Unify "byte code" to "bytecode". Also sprinkle :term: markup for it.

Doc/distutils/builtdist.rst

@@ -311,7 +311,7 @@ will reflect this and now has the form :file:`foo-1.0.win32-py2.0.exe`.  You
 have to create a separate installer for every Python version you want to
 support.
 
-The installer will try to compile pure modules into bytecode after installation
+The installer will try to compile pure modules into :term:`bytecode` after installation
 on the target system in normal and optimizing mode.  If you don't want this to
 happen for some reason, you can run the :command:`bdist_wininst` command with
 the :option:`--no-target-compile` and/or the :option:`--no-target-optimize`

Doc/documenting/markup.rst

@@ -210,7 +210,7 @@ The directives are:
 
 .. describe:: opcode
 
-   Describes a Python bytecode instruction.
+   Describes a Python :term:`bytecode` instruction.
 
 .. describe:: cmdoption
 

Doc/glossary.rst

@@ -21,12 +21,12 @@ Glossary
       <http://www.python.org/~guido/>`_, Python's creator.
     
    bytecode
-      The internal representation of a Python program in the interpreter. The
-      byte code is also cached in ``.pyc`` and ``.pyo`` files so that executing
-      the same file is faster the second time (recompilation from source to byte
-      code can be avoided).  This "intermediate language" is said to run on a
-      "virtual machine" that calls the subroutines corresponding to each
-      bytecode.
+      Python source code is compiled into bytecode, the internal representation
+      of a Python program in the interpreter.  The bytecode is also cached in
+      ``.pyc`` and ``.pyo`` files so that executing the same file is faster the
+      second time (recompilation from source to bytecode can be avoided).  This
+      "intermediate language" is said to run on a "virtual machine" that calls
+      the subroutines corresponding to each bytecode.
     
    classic class
       Any class which does not inherit from :class:`object`.  See

Doc/howto/functional.rst

@@ -448,7 +448,7 @@ Here's the simplest example of a generator function::
             yield i
 
 Any function containing a ``yield`` keyword is a generator function; this is
-detected by Python's bytecode compiler which compiles the function specially as
+detected by Python's :term:`bytecode` compiler which compiles the function specially as
 a result.
 
 When you call a generator function, it doesn't return a single value; instead it

Doc/library/compiler.rst

@@ -10,8 +10,8 @@ Python compiler package
 
 The Python compiler package is a tool for analyzing Python source code and
 generating Python bytecode.  The compiler contains libraries to generate an
-abstract syntax tree from Python source code and to generate Python bytecode
-from the tree.
+abstract syntax tree from Python source code and to generate Python
+:term:`bytecode` from the tree.
 
 The :mod:`compiler` package is a Python source to bytecode translator written in
 Python.  It uses the built-in parser and standard :mod:`parser` module to

Doc/library/dis.rst

@@ -1,12 +1,12 @@
 
 :mod:`dis` --- Disassembler for Python bytecode
-================================================
+===============================================
 
 .. module:: dis
    :synopsis: Disassembler for Python bytecode.
 
 
-The :mod:`dis` module supports the analysis of Python byte code by disassembling
+The :mod:`dis` module supports the analysis of Python :term:`bytecode` by disassembling
 it.  Since there is no Python assembler, this module defines the Python assembly
 language.  The Python bytecode which this module takes as an input is defined
 in the file  :file:`Include/opcode.h` and used by the compiler and the
@@ -120,8 +120,8 @@ The :mod:`dis` module defines the following functions and constants:
 
 .. _bytecodes:
 
-Python Byte Code Instructions
------------------------------
+Python Bytecode Instructions
+----------------------------
 
 The Python compiler currently generates the following bytecode instructions.
 

Doc/library/functions.rst

@@ -43,7 +43,7 @@ available.  They are listed here in alphabetical order.
    top-level package (the name up till the first dot) is returned, *not* the
    module named by *name*.  However, when a non-empty *fromlist* argument is
    given, the module named by *name* is returned.  This is done for
-   compatibility with the bytecode generated for the different kinds of import
+   compatibility with the :term:`bytecode` generated for the different kinds of import
    statement; when using ``import spam.ham.eggs``, the top-level package
    :mod:`spam` must be placed in the importing namespace, but when using ``from
    spam.ham import eggs``, the ``spam.ham`` subpackage must be used to find the

Doc/library/inspect.rst

@@ -69,7 +69,7 @@ attributes:
 +-----------+-----------------+---------------------------+-------+
 |           | func_code       | code object containing    |       |
 |           |                 | compiled function         |       |
-|           |                 | bytecode                  |       |
+|           |                 | :term:`bytecode`          |       |
 +-----------+-----------------+---------------------------+-------+
 |           | func_defaults   | tuple of any default      |       |
 |           |                 | values for arguments      |       |

Doc/library/parser.rst

@@ -319,7 +319,7 @@ Examples
 .. index:: builtin: compile
 
 The parser modules allows operations to be performed on the parse tree of Python
-source code before the bytecode is generated, and provides for inspection of the
+source code before the :term:`bytecode` is generated, and provides for inspection of the
 parse tree for information gathering purposes. Two examples are presented.  The
 simple example demonstrates emulation of the :func:`compile` built-in function
 and the complex example shows the use of a parse tree for information discovery.

Doc/reference/datamodel.rst

@@ -884,7 +884,7 @@ Internal types
          single: bytecode
          object: code
 
-      Code objects represent *byte-compiled* executable Python code, or *bytecode*.
+      Code objects represent *byte-compiled* executable Python code, or :term:`bytecode`.
       The difference between a code object and a function object is that the function
       object contains an explicit reference to the function's globals (the module in
       which it was defined), while a code object contains no context; also the default