pythoncapi
diff --git a/‎Doc/distutils/configfile.rst‎
Lines changed: 16 additions & 6 deletions b/‎Doc/distutils/configfile.rst‎
Lines changed: 16 additions & 6 deletions
diff --git a/‎Doc/distutils/packageindex.rst‎
Lines changed: 6 additions & 2 deletions b/‎Doc/distutils/packageindex.rst‎
Lines changed: 6 additions & 2 deletions
diff --git a/‎Doc/extending/embedding.rst‎
Lines changed: 1 addition & 1 deletion b/‎Doc/extending/embedding.rst‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎Doc/extending/extending.rst‎
Lines changed: 9 additions & 3 deletions b/‎Doc/extending/extending.rst‎
Lines changed: 9 additions & 3 deletions
diff --git a/‎Doc/extending/newtypes_tutorial.rst‎
Lines changed: 5 additions & 5 deletions b/‎Doc/extending/newtypes_tutorial.rst‎
Lines changed: 5 additions & 5 deletions
diff --git a/‎Doc/faq/library.rst‎
Lines changed: 3 additions & 1 deletion b/‎Doc/faq/library.rst‎
Lines changed: 3 additions & 1 deletion
diff --git a/‎Doc/faq/windows.rst‎
Lines changed: 20 additions & 6 deletions b/‎Doc/faq/windows.rst‎
Lines changed: 20 additions & 6 deletions
@@ -36,7 +36,9 @@ consequences:
 * installers can override anything in :file:`setup.cfg` using the command-line
   options to :file:`setup.py`
 
-The basic syntax of the configuration file is simple::
+The basic syntax of the configuration file is simple:
+
+.. code-block:: ini
 
    [command]
    option=value
@@ -51,9 +53,11 @@ option values can be split across multiple lines simply by indenting the
 continuation lines.
 
 You can find out the list of options supported by a particular command with the
-universal :option:`!--help` option, e.g. ::
+universal :option:`!--help` option, e.g.
+
+.. code-block:: shell-session
 
-   > python setup.py --help build_ext
+   $ python setup.py --help build_ext
    [...]
    Options for 'build_ext' command:
      --build-lib (-b)     directory for compiled extension modules
@@ -75,14 +79,18 @@ For example, say you want your extensions to be built "in-place"---that is, you
 have an extension :mod:`pkg.ext`, and you want the compiled extension file
 (:file:`ext.so` on Unix, say) to be put in the same source directory as your
 pure Python modules :mod:`pkg.mod1` and :mod:`pkg.mod2`.  You can always use the
-:option:`!--inplace` option on the command-line to ensure this::
+:option:`!--inplace` option on the command-line to ensure this:
+
+.. code-block:: sh
 
    python setup.py build_ext --inplace
 
 But this requires that you always specify the :command:`build_ext` command
 explicitly, and remember to provide :option:`!--inplace`. An easier way is to
 "set and forget" this option, by encoding it in :file:`setup.cfg`, the
-configuration file for this distribution::
+configuration file for this distribution:
+
+.. code-block:: ini
 
    [build_ext]
    inplace=1
@@ -103,7 +111,9 @@ information comes from the setup script, and some is automatically generated by
 the Distutils (such as the list of files installed).  But some of it has to be
 supplied as options to :command:`bdist_rpm`, which would be very tedious to do
 on the command-line for every run.  Hence, here is a snippet from the Distutils'
-own :file:`setup.cfg`::
+own :file:`setup.cfg`:
+
+.. code-block:: ini
 
    [bdist_rpm]
    release = 1
 
@@ -156,7 +156,9 @@ The :command:`register` and :command:`upload` commands both check for the
 existence of a :file:`.pypirc` file at the location :file:`$HOME/.pypirc`.
 If this file exists, the command uses the username, password, and repository
 URL configured in the file.  The format of a :file:`.pypirc` file is as
-follows::
+follows:
+
+.. code-block:: ini
 
     [distutils]
     index-servers =
@@ -179,7 +181,9 @@ Each section describing a repository defines three variables:
     will be prompt to type it when needed.
 
 If you want to define another server a new section can be created and
-listed in the *index-servers* variable::
+listed in the *index-servers* variable:
+
+.. code-block:: ini
 
     [distutils]
     index-servers =
 
@@ -323,7 +323,7 @@ options.  In this case, the :mod:`sysconfig` module is a useful tool to
 programmatically extract the configuration values that you will want to
 combine together.  For example:
 
-.. code-block:: python
+.. code-block:: pycon
 
    >>> import sysconfig
    >>> sysconfig.get_config_var('LIBS')
 
@@ -43,7 +43,9 @@ Let's create an extension module called ``spam`` (the favorite food of Monty
 Python fans...) and let's say we want to create a Python interface to the C
 library function :c:func:`system` [#]_. This function takes a null-terminated
 character string as argument and returns an integer.  We want this function to
-be callable from Python as follows::
+be callable from Python as follows:
+
+.. code-block:: pycon
 
    >>> import spam
    >>> status = spam.system("ls -l")
@@ -439,7 +441,9 @@ part of the Python interpreter, you will have to change the configuration setup
 and rebuild the interpreter.  Luckily, this is very simple on Unix: just place
 your file (:file:`spammodule.c` for example) in the :file:`Modules/` directory
 of an unpacked source distribution, add a line to the file
-:file:`Modules/Setup.local` describing your file::
+:file:`Modules/Setup.local` describing your file:
+
+.. code-block:: sh
 
    spam spammodule.o
 
@@ -450,7 +454,9 @@ subdirectory, but then you must first rebuild :file:`Makefile` there by running
 :file:`Setup` file.)
 
 If your module requires additional libraries to link with, these can be listed
-on the line in the configuration file as well, for instance::
+on the line in the configuration file as well, for instance:
+
+.. code-block:: sh
 
    spam spammodule.o -lX11
 
 
@@ -117,7 +117,7 @@ field mentioned above. ::
 The name of our type.  This will appear in the default textual representation of
 our objects and in some error messages, for example:
 
-.. code-block:: python
+.. code-block:: pycon
 
    >>> "" + custom.Custom()
    Traceback (most recent call last):
@@ -183,7 +183,7 @@ set to *NULL*. ::
 This adds the type to the module dictionary.  This allows us to create
 :class:`Custom` instances by calling the :class:`Custom` class:
 
-.. code-block:: python
+.. code-block:: pycon
 
    >>> import custom
    >>> mycustom = custom.Custom()
@@ -655,7 +655,7 @@ Python has a :term:`cyclic garbage collector (GC) <garbage collection>` that
 can identify unneeded objects even when their reference counts are not zero.
 This can happen when objects are involved in cycles.  For example, consider:
 
-.. code-block:: python
+.. code-block:: pycon
 
    >>> l = []
    >>> l.append(l)
@@ -672,7 +672,7 @@ Besides, in the second and third versions, we allowed subclassing
 :class:`Custom`, and subclasses may add arbitrary attributes.  For any of
 those two reasons, :class:`Custom` objects can participate in cycles:
 
-.. code-block:: python
+.. code-block:: pycon
 
    >>> import custom3
    >>> class Derived(custom3.Custom): pass
@@ -796,7 +796,7 @@ 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:
 
-.. code-block:: python
+.. code-block:: pycon
 
    >>> import sublist
    >>> s = sublist.SubList(range(3))
 
@@ -74,7 +74,9 @@ interpreter.
 
 Occasionally, a user's environment is so full that the :program:`/usr/bin/env`
 program fails; or there's no env program at all.  In that case, you can try the
-following hack (due to Alex Rezinsky)::
+following hack (due to Alex Rezinsky):
+
+.. code-block:: sh
 
    #! /bin/sh
    """:"
 
@@ -1,5 +1,7 @@
 :tocdepth: 2
 
+.. highlightlang:: none
+
 .. _windows-faq:
 
 =====================
@@ -39,12 +41,16 @@ or "Command prompt window".  Usually you can create such a window from your
 Start menu; under Windows 7 the menu selection is :menuselection:`Start -->
 Programs --> Accessories --> Command Prompt`.  You should be able to recognize
 when you have started such a window because you will see a Windows "command
-prompt", which usually looks like this::
+prompt", which usually looks like this:
+
+.. code-block:: doscon
 
    C:\>
 
 The letter may be different, and there might be other things after it, so you
-might just as easily see something like::
+might just as easily see something like:
+
+.. code-block:: doscon
 
    D:\YourName\Projects\Python>
 
@@ -60,11 +66,15 @@ program. So, how do you arrange for the interpreter to handle your Python?
 First, you need to make sure that your command window recognises the word
 "python" as an instruction to start the interpreter.  If you have opened a
 command window, you should try entering the command ``python`` and hitting
-return::
+return:
+
+.. code-block:: doscon
 
    C:\Users\YourName> python
 
-You should then see something like::
+You should then see something like:
+
+.. code-block:: pycon
 
    Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
@@ -73,7 +83,9 @@ You should then see something like::
 You have started the interpreter in "interactive mode". That means you can enter
 Python statements or expressions interactively and have them executed or
 evaluated while you wait.  This is one of Python's strongest features.  Check it
-by entering a few expressions of your choice and seeing the results::
+by entering a few expressions of your choice and seeing the results:
+
+.. code-block:: pycon
 
     >>> print("Hello")
     Hello
@@ -317,7 +329,9 @@ present, and ``getch()`` which gets one character without echoing it.
 How do I emulate os.kill() in Windows?
 --------------------------------------
 
-Prior to Python 2.7 and 3.2, to terminate a process, you can use :mod:`ctypes`::
+Prior to Python 2.7 and 3.2, to terminate a process, you can use :mod:`ctypes`:
+
+.. code-block:: python
 
    import ctypes