Fix "Python" casing in a few places (GH-9001) (GH-9313)
(cherry picked from commit 271818fe27
)
Co-authored-by: Andrés Delfino <adelfino@gmail.com>
This commit is contained in:
parent
ca2fa2841f
commit
b2ecb8b486
|
@ -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):
|
||||
. . .
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -556,7 +556,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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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()
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
Loading…
Reference in New Issue