doc: Formatting and typo fixes (#98974)

This commit is contained in:
jmcb 2022-11-07 04:55:55 +00:00 committed by GitHub
parent d7a00f1e8e
commit 728e42fcf5
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 10 additions and 10 deletions

View file

@ -167,7 +167,7 @@ How can I embed Python into a Windows application?
Embedding the Python interpreter in a Windows app can be summarized as follows:
1. Do _not_ build Python into your .exe file directly. On Windows, Python must
1. Do **not** build Python into your .exe file directly. On Windows, Python must
be a DLL to handle importing modules that are themselves DLL's. (This is the
first key undocumented fact.) Instead, link to :file:`python{NN}.dll`; it is
typically installed in ``C:\Windows\System``. *NN* is the Python version, a
@ -191,7 +191,7 @@ Embedding the Python interpreter in a Windows app can be summarized as follows:
2. If you use SWIG, it is easy to create a Python "extension module" that will
make the app's data and methods available to Python. SWIG will handle just
about all the grungy details for you. The result is C code that you link
*into* your .exe file (!) You do _not_ have to create a DLL file, and this
*into* your .exe file (!) You do **not** have to create a DLL file, and this
also simplifies linking.
3. SWIG will create an init function (a C function) whose name depends on the
@ -218,10 +218,10 @@ Embedding the Python interpreter in a Windows app can be summarized as follows:
5. There are two problems with Python's C API which will become apparent if you
use a compiler other than MSVC, the compiler used to build pythonNN.dll.
Problem 1: The so-called "Very High Level" functions that take FILE *
Problem 1: The so-called "Very High Level" functions that take ``FILE *``
arguments will not work in a multi-compiler environment because each
compiler's notion of a struct FILE will be different. From an implementation
standpoint these are very _low_ level functions.
compiler's notion of a ``struct FILE`` will be different. From an implementation
standpoint these are very low level functions.
Problem 2: SWIG generates the following code when generating wrappers to void
functions:

View file

@ -12,7 +12,7 @@ and `PEG <https://en.wikipedia.org/wiki/Parsing_expression_grammar>`_.
In particular, ``&`` followed by a symbol, token or parenthesized
group indicates a positive lookahead (i.e., is required to match but
not consumed), while ``!`` indicates a negative lookahead (i.e., is
required _not_ to match). We use the ``|`` separator to mean PEG's
required *not* to match). We use the ``|`` separator to mean PEG's
"ordered choice" (written as ``/`` in traditional PEG grammars). See
:pep:`617` for more details on the grammar's syntax.

View file

@ -330,7 +330,7 @@ statement, of a variable or attribute annotation and an optional assignment stat
annotated_assignment_stmt: `augtarget` ":" `expression`
: ["=" (`starred_expression` | `yield_expression`)]
The difference from normal :ref:`assignment` is that only single target is allowed.
The difference from normal :ref:`assignment` is that only a single target is allowed.
For simple names as assignment targets, if in class or module scope,
the annotations are evaluated and stored in a special class or module
@ -365,8 +365,8 @@ target, then the interpreter evaluates the target except for the last
IDEs.
.. versionchanged:: 3.8
Now annotated assignments allow same expressions in the right hand side as
the regular assignments. Previously, some expressions (like un-parenthesized
Now annotated assignments allow the same expressions in the right hand side as
regular assignments. Previously, some expressions (like un-parenthesized
tuple expressions) caused a syntax error.
@ -756,7 +756,7 @@ commas) the two steps are carried out separately for each clause, just
as though the clauses had been separated out into individual import
statements.
The details of the first step, finding and loading modules are described in
The details of the first step, finding and loading modules, are described in
greater detail in the section on the :ref:`import system <importsystem>`,
which also describes the various types of packages and modules that can
be imported, as well as all the hooks that can be used to customize