diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index 3466a48784..7289a921bd 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -241,15 +241,15 @@ should do to help ensure that your pull request is accepted. ``patchcheck`` is a simple automated patch checklist that guides a developer through the common patch generation checks. To run ``patchcheck``: - On *Unix* (including macOS):: +On *Unix* (including macOS):: - make patchcheck + make patchcheck - On *Windows* (after any successful build): +On *Windows* (after any successful build): - .. code-block:: dosbatch +.. code-block:: dosbatch - python.bat Tools\patchcheck\patchcheck.py + python.bat Tools\patchcheck\patchcheck.py The automated patch checklist runs through: diff --git a/internals/garbage-collector.rst b/internals/garbage-collector.rst index c2cbf6d72e..2dfba0afd6 100644 --- a/internals/garbage-collector.rst +++ b/internals/garbage-collector.rst @@ -131,15 +131,15 @@ class instances, classes in extension modules, etc. One could think that cycles are uncommon but the truth is that many internal references needed by the interpreter create cycles everywhere. Some notable examples: - * Exceptions contain traceback objects that contain a list of frames that - contain the exception itself. - * Module-level functions reference the module's dict (which is needed to resolve globals), - which in turn contains entries for the module-level functions. - * Instances have references to their class which itself references its module, and the module - contains references to everything that is inside (and maybe other modules) - and this can lead back to the original instance. - * When representing data structures like graphs, it is very typical for them to - have internal links to themselves. +* Exceptions contain traceback objects that contain a list of frames that + contain the exception itself. +* Module-level functions reference the module's dict (which is needed to resolve globals), + which in turn contains entries for the module-level functions. +* Instances have references to their class which itself references its module, and the module + contains references to everything that is inside (and maybe other modules) + and this can lead back to the original instance. +* When representing data structures like graphs, it is very typical for them to + have internal links to themselves. To correctly dispose of these objects once they become unreachable, they need to be identified first. Inside the function that identifies cycles, two doubly linked @@ -417,13 +417,13 @@ word-aligned addresses end in ``000``, leaving the last 3 bits available. The CPython GC makes use of two fat pointers that correspond to the extra fields of ``PyGC_Head`` discussed in the `Memory layout and object structure`_ section: - .. warning:: +.. warning:: - Because the presence of extra information, "tagged" or "fat" pointers cannot be - dereferenced directly and the extra information must be stripped off before - obtaining the real memory address. Special care needs to be taken with - functions that directly manipulate the linked lists, as these functions - normally assume the pointers inside the lists are in a consistent state. + Because the presence of extra information, "tagged" or "fat" pointers cannot be + dereferenced directly and the extra information must be stripped off before + obtaining the real memory address. Special care needs to be taken with + functions that directly manipulate the linked lists, as these functions + normally assume the pointers inside the lists are in a consistent state. * The ``_gc_prev`` field is normally used as the "previous" pointer to maintain the diff --git a/internals/parser.rst b/internals/parser.rst index f05d59b4ab..d98ce8705d 100644 --- a/internals/parser.rst +++ b/internals/parser.rst @@ -890,7 +890,7 @@ To activate verbose mode you can add the ``-d`` flag when executing Python: $ python -d file_to_test.py This will print **a lot** of output to ``stderr`` so is probably better to dump it to a file for further analysis. The output -consists of trace lines with the following structure: +consists of trace lines with the following structure:: ('>'|'-'|'+'|'!') []: ... @@ -902,9 +902,10 @@ character marks the type of the trace: * ``+`` indicates that a rule has been parsed correctly. * ``!`` indicates that an exception or an error has been detected and the parser is unwinding. -The part indicates the current index in the token array, the - part indicates what rule is being parsed and the part -indicates what alternative within that rule is being attempted. +The ```` part indicates the current index in the token array, +the ```` part indicates what rule is being parsed and +the ```` part indicates what alternative within that rule +is being attempted. References diff --git a/testing/coverage.rst b/testing/coverage.rst index ebd28b677b..0ebaf4b020 100644 --- a/testing/coverage.rst +++ b/testing/coverage.rst @@ -111,7 +111,7 @@ long as your venv is activated. For more info on venv see `Virtual Environment If this does not work for you for some reason, you should try using the in-development version of coverage.py to see if it has been updated as needed. -To do this you should clone/check out the development version of coverage.py: +To do this you should clone/check out the development version of coverage.py:: git clone https://github.com/nedbat/coveragepy