Fix "Python" casing in a few places (GH-9001)

andresdelfino · encukou · commit 271818fe279d · 2018-09-14T10:13:09.000-07:00
diff --git a/Doc/howto/descriptor.rst b/Doc/howto/descriptor.rst
@@ -11,7 +11,7 @@ Abstract
 --------
 
 Defines descriptors, summarizes the protocol, and shows how descriptors are
-called.  Examines a custom descriptor and several built-in python descriptors
+called.  Examines a custom descriptor and several built-in Python descriptors
 including functions, properties, static methods, and class methods.  Shows how
 each works by giving a pure Python equivalent and a sample application.
 
@@ -275,7 +275,7 @@ variable name.
 To support method calls, functions include the :meth:`__get__` method for
 binding methods during attribute access.  This means that all functions are
 non-data descriptors which return bound methods when they are invoked from an
-object.  In pure python, it works like this::
+object.  In pure Python, it works like this::
 
     class Function(object):
         . . .
diff --git a/Doc/howto/instrumentation.rst b/Doc/howto/instrumentation.rst
@@ -369,13 +369,13 @@ available:
 .. c:function:: python.function.entry(str filename, str funcname, int lineno, frameptr)
 
    This probe point indicates that execution of a Python function has begun.
-   It is only triggered for pure-python (bytecode) functions.
+   It is only triggered for pure-Python (bytecode) functions.
 
 .. c:function:: python.function.return(str filename, str funcname, int lineno, frameptr)
 
    This probe point is the converse of :c:func:`python.function.return`, and
    indicates that execution of a Python function has ended (either via
-   ``return``, or via an exception).  It is only triggered for pure-python
+   ``return``, or via an exception).  It is only triggered for pure-Python
    (bytecode) functions.
 
 
diff --git a/Doc/library/email.compat32-message.rst b/Doc/library/email.compat32-message.rst
@@ -5,7 +5,7 @@
 
 .. module:: email.message
    :synopsis: The base class representing email messages in a fashion
-              backward compatible with python3.2
+              backward compatible with Python 3.2
 
 
 The :class:`Message` class is very similar to the
diff --git a/Doc/library/idle.rst b/Doc/library/idle.rst
@@ -303,7 +303,7 @@ Python Docs
    and open docs.python.org showing the latest Python documentation.
 
 Turtle Demo
-   Run the turtledemo module with example python code and turtle drawings.
+   Run the turtledemo module with example Python code and turtle drawings.
 
 Additional help sources may be added here with the Configure IDLE dialog under
 the General tab.
diff --git a/Doc/library/imaplib.rst b/Doc/library/imaplib.rst
@@ -517,7 +517,7 @@ An :class:`IMAP4` instance has the following methods:
       create such tags.  Although it is an RFC violation and IMAP clients and
       servers are supposed to be strict, imaplib nonetheless continues to allow
       such tags to be created for backward compatibility reasons, and as of
-      python 3.6, handles them if they are sent from the server, since this
+      Python 3.6, handles them if they are sent from the server, since this
       improves real-world compatibility.
 
 .. method:: IMAP4.subscribe(mailbox)
diff --git a/Doc/library/inspect.rst b/Doc/library/inspect.rst
@@ -557,7 +557,7 @@ function.
       >>> sig.parameters['b'].annotation
       <class 'int'>
 
-   Accepts a wide range of python callables, from plain functions and classes to
+   Accepts a wide range of Python callables, from plain functions and classes to
    :func:`functools.partial` objects.
 
    Raises :exc:`ValueError` if no signature can be provided, and
diff --git a/Doc/library/pyclbr.rst b/Doc/library/pyclbr.rst
@@ -11,9 +11,9 @@
 --------------
 
 The :mod:`pyclbr` module provides limited information about the
-functions, classes, and methods defined in a python-coded module.  The
+functions, classes, and methods defined in a Python-coded module.  The
 information is sufficient to implement a module browser.  The
-information is extracted from the python source code rather than by
+information is extracted from the Python source code rather than by
 importing the module, so this module is safe to use with untrusted code.
 This restriction makes it impossible to use this module with modules not
 implemented in Python, including all standard and optional extension
diff --git a/Doc/library/syslog.rst b/Doc/library/syslog.rst
@@ -48,7 +48,7 @@ The module defines the following functions:
    .. versionchanged:: 3.2
       In previous versions, keyword arguments were not allowed, and *ident* was
       required.  The default for *ident* was dependent on the system libraries,
-      and often was ``python`` instead of the name of the python program file.
+      and often was ``python`` instead of the name of the Python program file.
 
 
 .. function:: closelog()
diff --git a/Doc/library/test.rst b/Doc/library/test.rst
@@ -1076,7 +1076,7 @@ The :mod:`test.support` module defines the following functions:
    Either this method or :func:`bind_port` should be used for any tests
    where a server socket needs to be bound to a particular port for the
    duration of the test.
-   Which one to use depends on whether the calling code is creating a python
+   Which one to use depends on whether the calling code is creating a Python
    socket, or if an unused port needs to be provided in a constructor
    or passed to an external program (i.e. the ``-accept`` argument to
    openssl's s_server mode).  Always prefer :func:`bind_port` over
diff --git a/Doc/library/unittest.mock-examples.rst b/Doc/library/unittest.mock-examples.rst
@@ -392,7 +392,7 @@ You can stack up multiple patch decorators using this pattern:
     >>> MyTest('test_something').test_something()
 
 When you nest patch decorators the mocks are passed in to the decorated
-function in the same order they applied (the normal *python* order that
+function in the same order they applied (the normal *Python* order that
 decorators are applied). This means from the bottom up, so in the example
 above the mock for ``test_module.ClassName2`` is passed in first.
 
diff --git a/Doc/library/unittest.mock.rst b/Doc/library/unittest.mock.rst
@@ -98,7 +98,7 @@ mock (or other object) during the test and restored when the test ends:
 .. note::
 
    When you nest patch decorators the mocks are passed in to the decorated
-   function in the same order they applied (the normal *python* order that
+   function in the same order they applied (the normal *Python* order that
    decorators are applied). This means from the bottom up, so in the example
    above the mock for ``module.ClassName1`` is passed in first.
 
diff --git a/Doc/library/zipapp.rst b/Doc/library/zipapp.rst
@@ -1,8 +1,8 @@
-:mod:`zipapp` --- Manage executable python zip archives
+:mod:`zipapp` --- Manage executable Python zip archives
 =======================================================
 
 .. module:: zipapp
-   :synopsis: Manage executable python zip archives
+   :synopsis: Manage executable Python zip archives
 
 .. versionadded:: 3.5
 
