22 files changed, 166 insertions, 64 deletions
diff --git a/Doc/library/2to3.rst b/Doc/library/2to3.rst
index f816946..ec59679 100644
--- a/Doc/library/2to3.rst
+++ b/Doc/library/2to3.rst
@@ -33,14 +33,18 @@ Here is a sample Python 2.x source file, :file:`example.py`::
    name = raw_input()
    greet(name)
 
-It can be converted to Python 3.x code via 2to3 on the command line::
+It can be converted to Python 3.x code via 2to3 on the command line:
+
+.. code-block:: shell-session
 
    $ 2to3 example.py
 
 A diff against the original source file is printed.  2to3 can also write the
 needed modifications right back to the source file.  (A backup of the original
 file is made unless :option:`-n` is also given.)  Writing the changes back is
-enabled with the :option:`-w` flag::
+enabled with the :option:`-w` flag:
+
+.. code-block:: shell-session
 
    $ 2to3 -w example.py
 
@@ -57,17 +61,23 @@ Comments and exact indentation are preserved throughout the translation process.
 By default, 2to3 runs a set of :ref:`predefined fixers <2to3-fixers>`.  The
 :option:`!-l` flag lists all available fixers.  An explicit set of fixers to run
 can be given with :option:`-f`.  Likewise the :option:`!-x` explicitly disables a
-fixer.  The following example runs only the ``imports`` and ``has_key`` fixers::
+fixer.  The following example runs only the ``imports`` and ``has_key`` fixers:
+
+.. code-block:: shell-session
 
    $ 2to3 -f imports -f has_key example.py
 
-This command runs every fixer except the ``apply`` fixer::
+This command runs every fixer except the ``apply`` fixer:
+
+.. code-block:: shell-session
 
    $ 2to3 -x apply example.py
 
 Some fixers are *explicit*, meaning they aren't run by default and must be
 listed on the command line to be run.  Here, in addition to the default fixers,
-the ``idioms`` fixer is run::
+the ``idioms`` fixer is run:
+
+.. code-block:: shell-session
 
    $ 2to3 -f all -f idioms example.py
 
@@ -113,7 +123,9 @@ This option implies the :option:`-w` flag as it would not make sense otherwise.
 
 The :option:`--add-suffix` option specifies a string to append to all output
 filenames.  The :option:`-n` flag is required when specifying this as backups
-are not necessary when writing to different filenames.  Example::
+are not necessary when writing to different filenames.  Example:
+
+.. code-block:: shell-session
 
    $ 2to3 -n -W --add-suffix=3 example.py
 
@@ -122,7 +134,9 @@ Will cause a converted file named ``example.py3`` to be written.
 .. versionadded:: 3.2.3
    The :option:`--add-suffix` option was added.
 
-To translate an entire project from one directory tree to another use::
+To translate an entire project from one directory tree to another use:
+
+.. code-block:: shell-session
 
    $ 2to3 --output-dir=python3-version/mycode -W -n python2-version/mycode
 
diff --git a/Doc/library/argparse.rst b/Doc/library/argparse.rst
index 10789e9..995c4ee 100644
--- a/Doc/library/argparse.rst
+++ b/Doc/library/argparse.rst
@@ -45,7 +45,9 @@ produces either the sum or the max::
    print(args.accumulate(args.integers))
 
 Assuming the Python code above is saved into a file called ``prog.py``, it can
-be run at the command line and provides useful help messages::
+be run at the command line and provides useful help messages:
+
+.. code-block:: shell-session
 
    $ python prog.py -h
    usage: prog.py [-h] [--sum] N [N ...]
@@ -60,7 +62,9 @@ be run at the command line and provides useful help messages::
     --sum       sum the integers (default: find the max)
 
 When run with the appropriate arguments, it prints either the sum or the max of
-the command-line integers::
+the command-line integers:
+
+.. code-block:: shell-session
 
    $ python prog.py 1 2 3 4
    4
@@ -68,7 +72,9 @@ the command-line integers::
    $ python prog.py 1 2 3 4 --sum
    10
 
-If invalid arguments are passed in, it will issue an error::
+If invalid arguments are passed in, it will issue an error:
+
+.. code-block:: shell-session
 
    $ python prog.py a b c
    usage: prog.py [-h] [--sum] N [N ...]
@@ -194,7 +200,9 @@ invoked on the command line.  For example, consider a file named
    args = parser.parse_args()
 
 The help for this program will display ``myprogram.py`` as the program name
-(regardless of where the program was invoked from)::
+(regardless of where the program was invoked from):
+
+.. code-block:: shell-session
 
    $ python myprogram.py --help
    usage: myprogram.py [-h] [--foo FOO]
@@ -596,7 +604,9 @@ the parser's help message. For example, consider a file named
    args = parser.parse_args()
 
 If ``-h`` or ``--help`` is supplied at the command line, the ArgumentParser
-help will be printed::
+help will be printed:
+
+.. code-block:: shell-session
 
    $ python myprogram.py --help
    usage: myprogram.py [-h] [--foo FOO]
diff --git a/Doc/library/ast.rst b/Doc/library/ast.rst
index 8c3b7e4..8d4ae2c 100644
--- a/Doc/library/ast.rst
+++ b/Doc/library/ast.rst
@@ -99,6 +99,7 @@ Abstract Grammar
 The abstract grammar is currently defined as follows:
 
 .. literalinclude:: ../../Parser/Python.asdl
+   :language: none
 
 
 :mod:`ast` Helpers
diff --git a/Doc/library/asyncio-dev.rst b/Doc/library/asyncio-dev.rst
index 156c5c0..b9557af 100644
--- a/Doc/library/asyncio-dev.rst
+++ b/Doc/library/asyncio-dev.rst
@@ -321,14 +321,18 @@ operations::
     print("Pending tasks at exit: %s" % asyncio.Task.all_tasks(loop))
     loop.close()
 
-Expected output::
+Expected output:
+
+.. code-block:: none
 
     (1) create file
     (2) write into file
     (3) close file
     Pending tasks at exit: set()
 
-Actual output::
+Actual output:
+
+.. code-block:: none
 
     (3) close file
     (2) write into file
@@ -369,13 +373,17 @@ Pending task destroyed
 If a pending task is destroyed, the execution of its wrapped :ref:`coroutine
 <coroutine>` did not complete. It is probably a bug and so a warning is logged.
 
-Example of log::
+Example of log:
+
+.. code-block:: none
 
     Task was destroyed but it is pending!
     task: <Task pending coro=<kill_me() done, defined at test.py:5> wait_for=<Future pending cb=[Task._wakeup()]>>
 
 :ref:`Enable the debug mode of asyncio <asyncio-debug-mode>` to get the
-traceback where the task was created. Example of log in debug mode::
+traceback where the task was created. Example of log in debug mode:
+
+.. code-block:: none
 
     Task was destroyed but it is pending!
     source_traceback: Object created at (most recent call last):
diff --git a/Doc/library/cgi.rst b/Doc/library/cgi.rst
index 0bc2c35..41219ee 100644
--- a/Doc/library/cgi.rst
+++ b/Doc/library/cgi.rst
@@ -442,7 +442,9 @@ installing a copy of this module file (:file:`cgi.py`) as a CGI script.  When
 invoked as a script, the file will dump its environment and the contents of the
 form in HTML form. Give it the right mode etc, and send it a request.  If it's
 installed in the standard :file:`cgi-bin` directory, it should be possible to
-send it a request by entering a URL into your browser of the form::
+send it a request by entering a URL into your browser of the form:
+
+.. code-block:: none
 
    http://yourhostname/cgi-bin/cgi.py?name=Joe+Blow&addr=At+Home
 
@@ -534,4 +536,3 @@ Common problems and solutions
    order the field values should be supplied in, but knowing whether a request
    was received from a conforming browser, or even from a browser at all, is
    tedious and error-prone.
-
diff --git a/Doc/library/cmd.rst b/Doc/library/cmd.rst
index 61ef0f6..f40cfdf 100644
--- a/Doc/library/cmd.rst
+++ b/Doc/library/cmd.rst
@@ -314,7 +314,9 @@ immediate playback::
 
 
 Here is a sample session with the turtle shell showing the help functions, using
-blank lines to repeat commands, and the simple record and playback facility::
+blank lines to repeat commands, and the simple record and playback facility:
+
+.. code-block:: none
 
     Welcome to the turtle shell.   Type help or ? to list commands.
 
@@ -373,4 +375,3 @@ blank lines to repeat commands, and the simple record and playback facility::
 
     (turtle) bye
     Thank you for using Turtle
-
diff --git a/Doc/library/decimal.rst b/Doc/library/decimal.rst
index 528f97b..971600c 100644
--- a/Doc/library/decimal.rst
+++ b/Doc/library/decimal.rst
@@ -163,7 +163,7 @@ an exception::
    >>> c.traps[FloatOperation] = True
    >>> Decimal(3.14)
    Traceback (most recent call last):
-   File "<stdin>", line 1, in <module>
+     File "<stdin>", line 1, in <module>
    decimal.FloatOperation: [<class 'decimal.FloatOperation'>]
    >>> Decimal('3.5') < 3.7
    Traceback (most recent call last):
diff --git a/Doc/library/doctest.rst b/Doc/library/doctest.rst
index c58f417..66a521e 100644
--- a/Doc/library/doctest.rst
+++ b/Doc/library/doctest.rst
@@ -88,14 +88,18 @@ Here's a complete but small example module::
        doctest.testmod()
 
 If you run :file:`example.py` directly from the command line, :mod:`doctest`
-works its magic::
+works its magic:
+
+.. code-block:: shell-session
 
    $ python example.py
    $
 
 There's no output!  That's normal, and it means all the examples worked.  Pass
 ``-v`` to the script, and :mod:`doctest` prints a detailed log of what
-it's trying, and prints a summary at the end::
+it's trying, and prints a summary at the end:
+
+.. code-block:: shell-session
 
    $ python example.py -v
    Trying:
@@ -109,7 +113,9 @@ it's trying, and prints a summary at the end::
        [1, 1, 2, 6, 24, 120]
    ok
 
-And so on, eventually ending with::
+And so on, eventually ending with:
+
+.. code-block:: none
 
    Trying:
        factorial(1e100)
@@ -196,7 +202,9 @@ file.  This can be done with the :func:`testfile` function::
 That short script executes and verifies any interactive Python examples
 contained in the file :file:`example.txt`.  The file content is treated as if it
 were a single giant docstring; the file doesn't need to contain a Python
-program!   For example, perhaps :file:`example.txt` contains this::
+program!   For example, perhaps :file:`example.txt` contains this:
+
+.. code-block:: none
 
    The ``example`` module
    ======================
diff --git a/Doc/library/email-examples.rst b/Doc/library/email-examples.rst
index ca08586..ad93b5c 100644
--- a/Doc/library/email-examples.rst
+++ b/Doc/library/email-examples.rst
@@ -59,7 +59,9 @@ way we could process it:
 
 .. literalinclude:: ../includes/email-read-alternative-new-api.py
 
-Up to the prompt, the output from the above is::
+Up to the prompt, the output from the above is:
+
+.. code-block:: none
 
     To: Penelope Pussycat <penelope@example.com>, Fabrette Pussycat <fabrette@example.com>
     From: Pepé Le Pew <pepe@example.com>
diff --git a/Doc/library/html.parser.rst b/Doc/library/html.parser.rst
index 16abb40..ac844a6 100644
--- a/Doc/library/html.parser.rst
+++ b/Doc/library/html.parser.rst
@@ -61,7 +61,9 @@ as they are encountered::
    parser.feed('<html><head><title>Test</title></head>'
                '<body><h1>Parse me!</h1></body></html>')
 
-The output will then be::
+The output will then be:
+
+.. code-block:: none
 
    Encountered a start tag: html
    Encountered a start tag: head
diff --git a/Doc/library/idle.rst b/Doc/library/idle.rst
index 9ca92ce..4a8c257 100644
--- a/Doc/library/idle.rst
+++ b/Doc/library/idle.rst
@@ -524,7 +524,7 @@ functions to be used from IDLE's Python shell.
 Command line usage
 ^^^^^^^^^^^^^^^^^^
 
-::
+.. code-block:: none
 
    idle.py [-c command] [-d] [-e] [-h] [-i] [-r file] [-s] [-t title] [-] [arg] ...
 
diff --git a/Doc/library/logging.config.rst b/Doc/library/logging.config.rst
index e196724..b4c9bc3 100644
--- a/Doc/library/logging.config.rst
+++ b/Doc/library/logging.config.rst
@@ -243,7 +243,9 @@ otherwise, the context is used to determine what to instantiate.
     handler.
 
   All *other* keys are passed through as keyword arguments to the
-  handler's constructor.  For example, given the snippet::
+  handler's constructor.  For example, given the snippet:
+
+  .. code-block:: yaml
 
       handlers:
         console:
@@ -352,7 +354,9 @@ it unambiguously, and then using the id in the source object's
 configuration to indicate that a connection exists between the source
 and the destination object with that id.
 
-So, for example, consider the following YAML snippet::
+So, for example, consider the following YAML snippet:
+
+.. code-block:: yaml
 
     formatters:
       brief:
@@ -409,7 +413,9 @@ to provide a 'factory' - a callable which is called with a
 configuration dictionary and which returns the instantiated object.
 This is signalled by an absolute import path to the factory being
 made available under the special key ``'()'``.  Here's a concrete
-example::
+example:
+
+.. code-block:: yaml
 
     formatters:
       brief:
@@ -626,7 +632,9 @@ configuration must be specified in a section called ``[logger_root]``.
    :func:`dictConfig`, so it's worth considering transitioning to this newer
    API when it's convenient to do so.
 
-Examples of these sections in the file are given below. ::
+Examples of these sections in the file are given below.
+
+.. code-block:: ini
 
    [loggers]
    keys=root,log02,log03,log04,log05,log06,log07
@@ -638,7 +646,9 @@ Examples of these sections in the file are given below. ::
    keys=form01,form02,form03,form04,form05,form06,form07,form08,form09
 
 The root logger must specify a level and a list of handlers. An example of a
-root logger section is given below. ::
+root logger section is given below.
+
+.. code-block:: ini
 
    [logger_root]
    level=NOTSET
@@ -655,7 +665,9 @@ appear in the ``[handlers]`` section. These names must appear in the
 file.
 
 For loggers other than the root logger, some additional information is required.
-This is illustrated by the following example. ::
+This is illustrated by the following example.
+
+.. code-block:: ini
 
    [logger_parser]
    level=DEBUG
@@ -673,7 +685,8 @@ indicate that messages are **not** propagated to handlers up the hierarchy. The
 say the name used by the application to get the logger.
 
 Sections which specify handler configuration are exemplified by the following.
-::
+
+.. code-block:: ini
 
    [handler_hand01]
    class=StreamHandler
@@ -693,7 +706,9 @@ a corresponding section in the configuration file.
 The ``args`` entry, when :func:`eval`\ uated in the context of the ``logging``
 package's namespace, is the list of arguments to the constructor for the handler
 class. Refer to the constructors for the relevant handlers, or to the examples
-below, to see how typical entries are constructed. ::
+below, to see how typical entries are constructed.
+
+.. code-block:: ini
 
    [handler_hand02]
    class=FileHandler
@@ -744,7 +759,9 @@ below, to see how typical entries are constructed. ::
    formatter=form09
    args=('localhost:9022', '/log', 'GET')
 
-Sections which specify formatter configuration are typified by the following. ::
+Sections which specify formatter configuration are typified by the following.
+
+.. code-block:: ini
 
    [formatter_form01]
    format=F1 %(asctime)s %(levelname)s %(message)s
@@ -780,5 +797,3 @@ condensed format.
 
    Module :mod:`logging.handlers`
       Useful handlers included with the logging module.
-
-
diff --git a/Doc/library/optparse.rst b/Doc/library/optparse.rst
index 9a4ba4e..e5f40f4 100644
--- a/Doc/library/optparse.rst
+++ b/Doc/library/optparse.rst
@@ -678,7 +678,9 @@ automatically adds a ``--version`` option to your parser. If it encounters
 this option on the command line, it expands your ``version`` string (by
 replacing ``%prog``), prints it to stdout, and exits.
 
-For example, if your script is called ``/usr/bin/foo``::
+For example, if your script is called ``/usr/bin/foo``:
+
+.. code-block:: shell-session
 
    $ /usr/bin/foo --version
    foo 1.0
@@ -728,14 +730,18 @@ program's usage message and an error message to standard error and exits with
 error status 2.
 
 Consider the first example above, where the user passes ``4x`` to an option
-that takes an integer::
+that takes an integer:
+
+.. code-block:: shell-session
 
    $ /usr/bin/foo -n 4x
    Usage: foo [options]
 
    foo: error: option -n: invalid integer value: '4x'
 
-Or, where the user fails to pass a value at all::
+Or, where the user fails to pass a value at all:
+
+.. code-block:: shell-session
 
    $ /usr/bin/foo -n
    Usage: foo [options]
diff --git a/Doc/library/pickletools.rst b/Doc/library/pickletools.rst
index 4c0a148..5e5939c 100644
--- a/Doc/library/pickletools.rst
+++ b/Doc/library/pickletools.rst
@@ -30,7 +30,9 @@ However, when the pickle file that you want to examine comes from an
 untrusted source, ``-m pickletools`` is a safer option because it does
 not execute pickle bytecode.
 
-For example, with a tuple ``(1, 2)`` pickled in file ``x.pickle``::
+For example, with a tuple ``(1, 2)`` pickled in file ``x.pickle``:
+
+.. code-block:: shell-session
 
     $ python -m pickle x.pickle
     (1, 2)
@@ -106,4 +108,3 @@ Programmatic Interface
    Returns a new equivalent pickle string after eliminating unused ``PUT``
    opcodes. The optimized pickle is shorter, takes less transmission time,
    requires less storage space, and unpickles more efficiently.
-
diff --git a/Doc/library/pyexpat.rst b/Doc/library/pyexpat.rst
index d6445f8..075a8b5 100644
--- a/Doc/library/pyexpat.rst
+++ b/Doc/library/pyexpat.rst
@@ -86,7 +86,9 @@ The :mod:`xml.parsers.expat` module contains two functions:
    separator.
 
    For example, if *namespace_separator* is set to a space character (``' '``) and
-   the following document is parsed::
+   the following document is parsed:
+
+   .. code-block:: xml
 
       <?xml version="1.0"?>
       <root xmlns    = "http://default-namespace.org/"
diff --git a/Doc/library/shutil.rst b/Doc/library/shutil.rst
index e9ba4e6..a1cf241 100644
--- a/Doc/library/shutil.rst
+++ b/Doc/library/shutil.rst
@@ -603,7 +603,9 @@ found in the :file:`.ssh` directory of the user::
     >>> make_archive(archive_name, 'gztar', root_dir)
     '/Users/tarek/myarchive.tar.gz'
 
-The resulting archive contains::
+The resulting archive contains:
+
+.. code-block:: shell-session
 
     $ tar -tzvf /Users/tarek/myarchive.tar.gz
     drwx------ tarek/staff       0 2010-02-01 16:23:40 ./
diff --git a/Doc/library/socketserver.rst b/Doc/library/socketserver.rst
index 98d2c46..087f4e0 100644
--- a/Doc/library/socketserver.rst
+++ b/Doc/library/socketserver.rst
@@ -479,7 +479,9 @@ This is the client side::
 
 The output of the example should look something like this:
 
-Server::
+Server:
+
+.. code-block:: shell-session
 
    $ python TCPServer.py
    127.0.0.1 wrote:
@@ -487,7 +489,9 @@ Server::
    127.0.0.1 wrote:
    b'python is nice'
 
-Client::
+Client:
+
+.. code-block:: shell-session
 
    $ python TCPClient.py hello world with TCP
    Sent:     hello world with TCP
@@ -599,7 +603,9 @@ An example for the :class:`ThreadingMixIn` class::
        server.server_close()
 
 
-The output of the example should look something like this::
+The output of the example should look something like this:
+
+.. code-block:: shell-session
 
    $ python ThreadedTCPServer.py
    Server loop running in thread: Thread-1
diff --git a/Doc/library/subprocess.rst b/Doc/library/subprocess.rst
index f469107..356605f 100644
--- a/Doc/library/subprocess.rst
+++ b/Doc/library/subprocess.rst
@@ -950,20 +950,23 @@ been imported from the :mod:`subprocess` module.
 Replacing /bin/sh shell backquote
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-::
+.. code-block:: bash
 
    output=`mycmd myarg`
-   # becomes
-   output = check_output(["mycmd", "myarg"])
 
+becomes::
+
+   output = check_output(["mycmd", "myarg"])
 
 Replacing shell pipeline
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-::
+.. code-block:: bash
 
    output=`dmesg | grep hda`
-   # becomes
+
+becomes::
+
    p1 = Popen(["dmesg"], stdout=PIPE)
    p2 = Popen(["grep", "hda"], stdin=p1.stdout, stdout=PIPE)
    p1.stdout.close()  # Allow p1 to receive a SIGPIPE if p2 exits.
@@ -973,10 +976,14 @@ The p1.stdout.close() call after starting the p2 is important in order for p1
 to receive a SIGPIPE if p2 exits before p1.
 
 Alternatively, for trusted input, the shell's own pipeline support may still
-be used directly::
+be used directly:
+
+.. code-block:: bash
 
    output=`dmesg | grep hda`
-   # becomes
+
+becomes::
+
    output=check_output("dmesg | grep hda", shell=True)
 
 
diff --git a/Doc/library/sys.rst b/Doc/library/sys.rst
index 9f70a13..ed5db05 100644
--- a/Doc/library/sys.rst
+++ b/Doc/library/sys.rst
@@ -1282,7 +1282,9 @@ always available.
 
    A dictionary of the various implementation-specific flags passed through
    the :option:`-X` command-line option.  Option names are either mapped to
-   their values, if given explicitly, or to :const:`True`.  Example::
+   their values, if given explicitly, or to :const:`True`.  Example:
+
+   .. code-block:: shell-session
 
       $ ./python -Xa=b -Xc
       Python 3.2a3+ (py3k, Oct 16 2010, 20:14:50)
diff --git a/Doc/library/sysconfig.rst b/Doc/library/sysconfig.rst
index 0b0df9b..c51567a 100644
--- a/Doc/library/sysconfig.rst
+++ b/Doc/library/sysconfig.rst
@@ -229,7 +229,9 @@ Other functions
 Using :mod:`sysconfig` as a script
 ----------------------------------
 
-You can use :mod:`sysconfig` as a script with Python's *-m* option::
+You can use :mod:`sysconfig` as a script with Python's *-m* option:
+
+.. code-block:: shell-session
 
     $ python -m sysconfig
     Platform: "macosx-10.4-i386"
diff --git a/Doc/library/tarfile.rst b/Doc/library/tarfile.rst
index 90a5852..5b95ef3 100644
--- a/Doc/library/tarfile.rst
+++ b/Doc/library/tarfile.rst
@@ -654,25 +654,35 @@ The :mod:`tarfile` module provides a simple command line interface to interact
 with tar archives.
 
 If you want to create a new tar archive, specify its name after the :option:`-c`
-option and then list the filename(s) that should be included::
+option and then list the filename(s) that should be included:
+
+.. code-block:: shell-session
 
     $ python -m tarfile -c monty.tar  spam.txt eggs.txt
 
-Passing a directory is also acceptable::
+Passing a directory is also acceptable:
+
+.. code-block:: shell-session
 
     $ python -m tarfile -c monty.tar life-of-brian_1979/
 
 If you want to extract a tar archive into the current directory, use
-the :option:`-e` option::
+the :option:`-e` option:
+
+.. code-block:: shell-session
 
     $ python -m tarfile -e monty.tar
 
 You can also extract a tar archive into a different directory by passing the
-directory's name::
+directory's name:
+
+.. code-block:: shell-session
 
     $ python -m tarfile -e monty.tar  other-dir/
 
-For a list of the files in a tar archive, use the :option:`-l` option::
+For a list of the files in a tar archive, use the :option:`-l` option:
+
+.. code-block:: shell-session
 
     $ python -m tarfile -l monty.tar
 
diff --git a/Doc/library/zipimport.rst b/Doc/library/zipimport.rst
index 0a0f175..46b8c24 100644
--- a/Doc/library/zipimport.rst
+++ b/Doc/library/zipimport.rst
@@ -147,7 +147,9 @@ Examples
 --------
 
 Here is an example that imports a module from a ZIP archive - note that the
-:mod:`zipimport` module is not explicitly used. ::
+:mod:`zipimport` module is not explicitly used.
+
+.. code-block:: shell-session
 
    $ unzip -l example.zip
    Archive:  example.zip