mirror of https://github.com/python/cpython.git
doc: Formatting and typo fixes (GH-98974)
(cherry picked from commit 728e42fcf5
)
Co-authored-by: jmcb <joelsgp@protonmail.com>
This commit is contained in:
parent
5f83209d89
commit
3dbf2708f5
|
@ -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:
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue