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

@@ -20,13 +20,13 @@ Glossary
       Benevolent Dictator For Life, a.k.a. `Guido van Rossum
       <http://www.python.org/~guido/>`_, Python's creator.
     
-   byte code
-      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.
+   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,14 +1,14 @@
 
-:mod:`dis` --- Disassembler for Python byte code
-================================================
+:mod:`dis` --- Disassembler for Python bytecode
+===============================================
 
 .. module:: dis
-   :synopsis: Disassembler for Python byte code.
+   :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 byte code which this module takes as an input is defined
+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
 interpreter.
 
@@ -35,7 +35,7 @@ The :mod:`dis` module defines the following functions and constants:
    Disassemble the *bytesource* object. *bytesource* can denote either a module, a
    class, a method, a function, or a code object.   For a module, it disassembles
    all functions.  For a class, it disassembles all methods.  For a single code
-   sequence, it prints one line per byte code instruction.  If no object is
+   sequence, it prints one line per bytecode instruction.  If no object is
    provided, it disassembles the last traceback.
 
 
@@ -70,12 +70,12 @@ The :mod:`dis` module defines the following functions and constants:
 
 .. data:: opname
 
-   Sequence of operation names, indexable using the byte code.
+   Sequence of operation names, indexable using the bytecode.
 
 
 .. data:: opmap
 
-   Dictionary mapping byte codes to operation names.
+   Dictionary mapping bytecodes to operation names.
 
 
 .. data:: cmp_op
@@ -85,45 +85,45 @@ The :mod:`dis` module defines the following functions and constants:
 
 .. data:: hasconst
 
-   Sequence of byte codes that have a constant parameter.
+   Sequence of bytecodes that have a constant parameter.
 
 
 .. data:: hasfree
 
-   Sequence of byte codes that access a free variable.
+   Sequence of bytecodes that access a free variable.
 
 
 .. data:: hasname
 
-   Sequence of byte codes that access an attribute by name.
+   Sequence of bytecodes that access an attribute by name.
 
 
 .. data:: hasjrel
 
-   Sequence of byte codes that have a relative jump target.
+   Sequence of bytecodes that have a relative jump target.
 
 
 .. data:: hasjabs
 
-   Sequence of byte codes that have an absolute jump target.
+   Sequence of bytecodes that have an absolute jump target.
 
 
 .. data:: haslocal
 
-   Sequence of byte codes that access a local variable.
+   Sequence of bytecodes that access a local variable.
 
 
 .. data:: hascompare
 
-   Sequence of byte codes of Boolean operations.
+   Sequence of bytecodes of Boolean operations.
 
 
 .. _bytecodes:
 
-Python Byte Code Instructions
------------------------------
+Python Bytecode Instructions
+----------------------------
 
-The Python compiler currently generates the following byte code instructions.
+The Python compiler currently generates the following bytecode instructions.
 
 
 .. opcode:: STOP_CODE ()
@@ -652,31 +652,31 @@ the more significant byte last.
 
 .. opcode:: JUMP_FORWARD (delta)
 
-   Increments byte code counter by *delta*.
+   Increments bytecode counter by *delta*.
 
 
 .. opcode:: JUMP_IF_TRUE (delta)
 
-   If TOS is true, increment the byte code counter by *delta*.  TOS is left on the
+   If TOS is true, increment the bytecode counter by *delta*.  TOS is left on the
    stack.
 
 
 .. opcode:: JUMP_IF_FALSE (delta)
 
-   If TOS is false, increment the byte code counter by *delta*.  TOS is not
+   If TOS is false, increment the bytecode counter by *delta*.  TOS is not
    changed.
 
 
 .. opcode:: JUMP_ABSOLUTE (target)
 
-   Set byte code counter to *target*.
+   Set bytecode counter to *target*.
 
 
 .. opcode:: FOR_ITER (delta)
 
    ``TOS`` is an iterator.  Call its :meth:`next` method.  If this yields a new
    value, push it on the stack (leaving the iterator below it).  If the iterator
-   indicates it is exhausted  ``TOS`` is popped, and the byte code counter is
+   indicates it is exhausted  ``TOS`` is popped, and the bytecode counter is
    incremented by *delta*.
 
 .. % \begin{opcodedesc}{FOR_LOOP}{delta}

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
@@ -905,7 +905,7 @@ Internal types
       used by the bytecode; :attr:`co_names` is a tuple containing the names used by
       the bytecode; :attr:`co_filename` is the filename from which the code was
       compiled; :attr:`co_firstlineno` is the first line number of the function;
-      :attr:`co_lnotab` is a string encoding the mapping from byte code offsets to
+      :attr:`co_lnotab` is a string encoding the mapping from bytecode offsets to
       line numbers (for details see the source code of the interpreter);
       :attr:`co_stacksize` is the required stack size (including local variables);
       :attr:`co_flags` is an integer encoding a number of flags for the interpreter.