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
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
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:
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.
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
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.
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