8000 Remove extra whitespace in the documentation files (#832) · python/devguide@07d9d53 · GitHub
[go: up one dir, main page]
Skip to content

Commit 07d9d53

Browse files
slatenyslateny
authored
Remove extra whitespace in the documentation files (#832)
1 parent 9cf776c commit 07d9d53

11 files changed

+61
-61
lines changed

‎appendix.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
Appendix: Topics
1+
Appendix: Topics
22
================
33

44
Basics for contributors
@@ -67,4 +67,4 @@ Testing and continuous integration
6767
* :doc:`buildbots`
6868
* :doc:`buildworker`
6969
* :doc:`coverity`
70-
70+

‎c-api.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -74,7 +74,7 @@ see below).
7474

7575
Guidelines for expanding/changing the public API:
7676

77-
- Make sure the new API follows reference counting conventions.
77+
- Make sure the new API follows reference counting conventions.
7878
(Following them makes the API easier to reason about, and easier use
7979
in other Python implementations.)
8080

@@ -170,7 +170,7 @@ Guidelines for adding to the Limited API
170170

171171
- Think about ease of use for the user.
172172

173-
- In C, ease of use itself is not very important; what is useful is
173+
- In C, ease of use itself is not very important; what is useful is
174174
reducing boilerplate code needed to use the API. Bugs like to hide in
175175
boiler plates.
176176

‎committing.rst

Lines changed: 26 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -15,36 +15,36 @@ Before you can accept a pull request, you need to make sure that it is ready
1515
to enter the public source tree. Ask yourself the following questions:
1616

1717
* **Are there ongoing discussions at** ``bugs.python.org`` **(b.p.o.)?**
18-
Read the linked b.p.o. issue. If there are ongoing discussions, then
18+
Read the linked b.p.o. issue. If there are ongoing discussions, then
1919
we need to have a resolution there before we can merge the pull request.
2020

21-
* **Was the pull request first made against the appropriate branch?**
21+
* **Was the pull request first made against the appropriate branch?**
2222
The only branch that receives new features is ``main``, the
2323
in-development branch. Pull requests should only target bug-fix branches
2424
if an issue appears in only that version and possibly older versions.
2525

26-
* **Are the changes acceptable?**
27-
If you want to share your work-in-progress code on a feature or bugfix,
28-
then you can open a ``WIP``-prefixed pull request, publish patches on
26+
* **Are the changes acceptable?**
27+
If you want to share your work-in-progress code on a feature or bugfix,
28+
then you can open a ``WIP``-prefixed pull request, publish patches on
2929
the `issue tracker`_, or create a public fork of the repository.
3030

31-
* **Do the checks on the pull request show that the test suite passes?**
31+
* **Do the checks on the pull request show that the test suite passes?**
3232
Make sure that all of the status checks are passing.
3333

34-
* **Is the patch in a good state?**
35-
Check :ref:`patch` and :ref:`helptriage` to review what is expected of
34+
* **Is the patch in a good state?**
35+
Check :ref:`patch` and :ref:`helptriage` to review what is expected of
3636
a patch.
3737

38-
* **Does the patch break backwards-compatibility without a strong reason?**
39-
:ref:`Run the entire test suite <runtests>` to make sure that everything
40-
still passes. If there is a change to the semantics, then there needs to
41-
be a strong reason, because it will cause some peoples' code to break.
38+
* **Does the patch break backwards-compatibility without a strong reason?**
39+
:ref:`Run the entire test suite <runtests>` to make sure that everything
40+
still passes. If there is a change to the semantics, then there needs to
41+
be a strong reason, because it will cause some peoples' code to break.
4242
If you are unsure if the breakage is worth it, then ask on python-dev.
43-
43+
4444
* **Does documentation need to be updated?**
45-
If the pull request introduces backwards-incompatible changes (e.g.
46-
deprecating or removing a feature), then make sure that those changes
47-
are reflected in the documentation before you merge the pull request.
45+
If the pull request introduces backwards-incompatible changes (e.g.
46+
deprecating or removing a feature), then make sure that those changes
47+
are reflected in the documentation before you merge the pull request.
4848

4949
* **Were appropriate labels added to signify necessary backporting of the pull request?**
5050
If it is determined that a pull request needs to be
@@ -55,21 +55,21 @@ to enter the public source tree. Ask yourself the following questions:
5555
core developers and members of the `Python Triage Team`_ can apply
5656
labels to GitHub pull requests).
5757

58-
* **Does the pull request pass a check indicating that the submitter has signed the CLA?**
58+
* **Does the pull request pass a check indicating that the submitter has signed the CLA?**
5959
Make sure that the contributor has signed a `Contributor
60-
Licensing Agreement <https://www.python.org/psf/contrib/contrib-form/>`_
61-
(CLA), unless their change has no possible intellectual property
62-
associated with it (e.g. fixing a spelling mistake in documentation).
60+
Licensing Agreement <https://www.python.org/psf/contrib/contrib-form/>`_
61+
(CLA), unless their change has no possible intellectual property
62+
associated with it (e.g. fixing a spelling mistake in documentation).
6363
To check if a contributor’s CLA has been received, go
6464
to `Check Python CLA <https://check-python-cla.herokuapp.com/>`_ and
6565
put in their GitHub username. For further questions about the CLA
6666
process, write to contributors@python.org.
6767

68-
* **Were** ``What's New in Python`` **and** ``Misc/NEWS.d/next`` **updated?**
69-
If the change is particularly interesting for end users (e.g. new features,
70-
significant improvements, or backwards-incompatible changes), then an
71-
entry in the ``What's New in Python`` document (in ``Doc/whatsnew/``) should
72-
be added as well. Changes that affect only documentation generally do not
68+
* **Were** ``What's New in Python`` **and** ``Misc/NEWS.d/next`` **updated?**
69+
If the change is particularly interesting for end users (e.g. new features,
70+
significant improvements, or backwards-incompatible changes), then an
71+
entry in the ``What's New in Python`` document (in ``Doc/whatsnew/``) should
72+
be added as well. Changes that affect only documentation generally do not
7373
require a ``NEWS`` entry. (See the following section for more information.)
7474

7575

@@ -161,7 +161,7 @@ Python repositories, so you need to be careful with your workflow:
161161
for maintenance work before it is integrated into the main repository.
162162

163163
* **You should not commit directly into the** ``main`` **branch, or any of the maintenance branches.**
164-
You should commit against your own feature branch, and then create a
164+
You should commit against your own feature branch, and then create a
165165
pull request.
166166

167167
* **For a small change, you can make a quick edit through the GitHub web UI.**

‎compiler.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -473,9 +473,9 @@ Changing this number will lead to all .pyc files with the old ``MAGIC_NUMBER``
473473
to be recompiled by the interpreter on import. Whenever ``MAGIC_NUMBER`` is
474474
changed, the ranges in the ``magic_values`` array in :file:`PC/launcher.c`
475475
must also be updated. Changes to :file:`Lib/importlib/_bootstrap_external.py`
476-
will take effect only after running ``make regen-importlib``. Running this
477-
command before adding the new bytecode target to :file:`Python/ceval.c` will
478-
result in an error. You should only run ``make regen-importlib`` after the new
476+
will take effect only after running ``make regen-importlib``. Running this
477+
command before adding the new bytecode target to :file:`Python/ceval.c` will
478+
result in an error. You should only run ``make regen-importlib`` after the new
479479
bytecode target has been added.
480480

481481
.. note:: On Windows, running the ``./build.bat`` script will automatically

‎coverage.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -207,8 +207,8 @@ C extension is installed. You can check this with::
207207
./python COVERAGEDIR --version
208208

209209
If it says 'without C extension', then you will need to build the C extension.
210-
Assuming that coverage.py's clone is at ``COVERAGEDIR`` and your clone of CPython
211-
is at ``CPYTHONDIR``, you can do this by executing the following in your coverage.py
210+
Assuming that coverage.py's clone is at ``COVERAGEDIR`` and your clone of CPython
211+
is at ``CPYTHONDIR``, you can do this by executing the following in your coverage.py
212212
clone::
213213

214214
CPPFLAGS="-I CPYTHONDIR -I CPYTHONDIR/Include" CPYTHONDIR/python setup.py build_ext --inplace

‎documenting.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1781,7 +1781,7 @@ How is a coordinator elected?
17811781
There is no election; each translation has to sort this out. Here are some suggestions.
17821782

17831783
- Coordinator requests are to be public on the `translation mailing list <translation_ml_>`_.
1784-
- If the given language has a native core dev, the core dev has their
1784+
- If the given language has a native core dev, the core dev has their
17851785
say on the choice.
17861786
- Anyone who wants to become coordinator for their native language and shows
17871787
motivation by translating and building a community will be named
@@ -1803,7 +1803,7 @@ Ask on the `translation mailing list <translation_ml_>`_, or better, make a PR o
18031803
I have a translation, but it's not in git. What should I do?
18041804
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
18051805

1806-
You can ask for help on the `translation mailing list <translation_ml_>`_, and
1806+
You can ask for help on the `translation mailing list <translation_ml_>`_, and
18071807
the team will help you create an appropriate repository. You can still use tools like transifex,
18081808
if you like.
18091809

‎garbage_collector.rst

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -65,7 +65,7 @@ Normally the C structure supporting a regular Python object looks as follows:
6565
| *ob_type | |
6666
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
6767
| ... |
68-
68+
6969
7070
In order to support the garbage collector, the memory layout of objects is altered
7171
to accommodate extra information **before** the normal layout:
@@ -82,7 +82,7 @@ to accommodate extra information **before** the normal layout:
8282
| *ob_type | |
8383
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
8484
| ... |
85-
85+
8686
8787
In this way the object can be treated as a normal python object and when the extra
8888
information associated to the GC is needed the previous fields can be accessed by a
@@ -179,7 +179,7 @@ Every object that supports garbage collection will have an extra reference
179179
count field initialized to the reference count (``gc_ref`` in the figures)
180180
of that object when the algorithm starts. This is because the algorithm needs
181181
to modify the reference count to do the computations and in this way the
182-
interpreter will not modify the real reference count field.
182+
interpreter will not modify the real reference count field.
183183

184184
.. figure:: images/python-cyclic-gc-1-new-page.png
185185

@@ -219,10 +219,10 @@ they started originally) and setting its ``gc_refs`` field to 1. This is what ha
219219
to ``link_2`` and ``link_3`` below as they are reachable from ``link_1``. From the
220220
state in the previous image and after examining the objects referred to by ``link_1``
221221
the GC knows that ``link_3`` is reachable after all, so it is moved back to the
222-
original list and its ``gc_refs`` field is set to 1 so that if the GC visits it again,
222+
original list and its ``gc_refs`` field is set to 1 so that if the GC visits it again,
223223
it will know that it's reachable. To avoid visiting an object twice, the GC marks all
224-
objects that have already been visited once (by unsetting the ``PREV_MASK_COLLECTING``
225-
flag) so that if an object that has already been processed is referenced by some other
224+
objects that have already been visited once (by unsetting the ``PREV_MASK_COLLECTING``
225+
flag) so that if an object that has already been processed is referenced by some other
226226
object, the GC does not process it twice.
227227

228228
.. figure:: images/python-cyclic-gc-5-new-page.png
@@ -337,7 +337,7 @@ specifically in a generation by calling ``gc.collect(generation=NUM)``.
337337
>>> import gc
338338
>>> class MyObj:
339339
... pass
340-
...
340+
...
341341
342342
# Move everything to the last generation so it's easier to inspect
343343
# the younger generations.
@@ -462,7 +462,7 @@ benefit from delayed tracking:
462462
when created. During garbage collection it is determined whether any surviving
463463
tuples can be untracked. A tuple can be untracked if all of its contents are
464464
already not tracked. Tuples are examined for untracking in all garbage collection
465-
cycles. It may take more than one cycle to untrack a tuple.
465+
cycles. It may take more than one cycle to untrack a tuple.
466466

467467
* Dictionaries containing only immutable objects also do not need to be tracked.
468468
Dictionaries are untracked when created. If a tracked item is inserted into a
@@ -472,7 +472,7 @@ benefit from delayed tracking:
472472

473473
The garbage collector module provides the Python function ``is_tracked(obj)``, which returns
474474
the current tracking status of the object. Subsequent garbage collections may change the
475-
tracking status of the object.
475+
tracking status of the object.
476476

477477
.. code-block:: python
478478

‎parser.rst

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -69,7 +69,7 @@ loads the entire program in memory before parsing it but also allows the parser
6969
to backtrack arbitrarily. This is made efficient by memoizing the rules already
7070
matched for each position. The cost of the memoization cache is that the parser
7171
will naturally use more memory than a simple LL(1) parser, which normally are
72-
table-based.
72+
table-based.
7373

7474

7575
Key ideas
@@ -329,7 +329,7 @@ different set of actions, keeping everything else apart from said actions
329329
identical in both files. As an example of a grammar with Python actions, the
330330
piece of the parser generator that parses grammar files is bootstrapped from a
331331
meta-grammar file with Python actions that generate the grammar tree as a result
332-
of the parsing.
332+
of the parsing.
333333

334334
In the specific case of the PEG grammar for Python, having actions allows
335335
directly describing how the AST is composed in the grammar itself, making it
@@ -525,7 +525,7 @@ parser. It contains the following pieces:
525525
* A PEG meta-grammar that automatically generates a Python parser that is used for the parser generator itself
526526
(this means that there are no manually-written parsers). The meta-grammar is
527527
located at :file:`Tools/peg_generator/pegen/metagrammar.gram`.
528-
* A generated parser (using the parser generator) that can directly produce C and Python AST objects.
528+
* A generated parser (using the parser generator) that can directly produce C and Python AST objects.
529529

530530
The source code for Pegen lives at :file:`Tools/peg_generator/pegen` but normally all typical commands to interact
531531
with the parser generator are executed from the main makefile.
@@ -606,7 +606,7 @@ and the parser just receives tokens from it.
606606
Memoization
607607
~~~~~~~~~~~
608608

609-
As described previously, to avoid exponential time complexity in the parser, memoization is used.
609+
As described previously, to avoid exponential time complexity in the parser, memoization is used.
610610

611611
The C parser used by Python is highly optimized and memoization can be expensive both in memory and time. Although
612612
the memory cost is obvious (the parser needs memory for storing previous results in the cache) the execution time
@@ -785,13 +785,13 @@ displayed when the error is reported.
785785
a syntax error **after** valid code triggers the rule or not. For example: ::
786786

787787
<valid python code> $ 42
788-
788+
789789
Should trigger the syntax error in the ``$`` character. If your rule is not correctly defined this
790790
won't happen. For example, if you try to define a rule to match Python 2 style ``print`` statements
791791
to make a better error message and you define it as: ::
792792

793793
invalid_print: "print" expression
794-
794+
795795
This will **seem** to work because the parser will correctly parse ``print(something)`` because it is valid
796796
code and the second phase will never execute but if you try to parse ``print(something) $ 3`` the first pass
797797
of the parser will fail (because of the ``$``) and in the second phase, the rule will match the
@@ -818,7 +818,7 @@ from them or to do extra processing on the generated tree.
818818
AST to decide if is valid or not but this will render the `official grammar
819819
<https://docs.python.org/3/reference/grammar.html>`_ partially incorrect
820820
(because actions are not included) and will make it more difficult for other
821-
Python implementations to adapt the grammar to their own needs.
821+
Python implementations to adapt the grammar to their own needs.
822822

823823
As a general rule, if an action spawns multiple lines or requires something more
824824
complicated than a single expression of C code, is normally better to create a
@@ -875,7 +875,7 @@ Verbose mode
875875
When Python is compiled in debug mode (by adding ``--with-pydebug`` when running the configure step in Linux or by
876876
adding ``-d`` when calling the :file:`PCbuild/python.bat` script in Windows), it is possible to activate a **very** verbose
877877
mode in the generated parser. This is very useful to debug the generated parser and to understand how it works, but it
878-
can be a bit hard to understand at first.
878+
can be a bit hard to understand at first.
879879

880880
.. note::
881881

‎pullrequest.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -453,7 +453,7 @@ Leaving a Pull Request Review on GitHub
453453
---------------------------------------
454454

455455
When you review a pull request, you should provide additional details and context
456-
of your review process.
456+
of your review process.
457457

458458
Instead of simply "approving" the pull request, leave comments. For example:
459459

‎runtests.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -50,14 +50,14 @@ path to the test case::
5050

5151
./python -m unittest -v test.test_abc.TestABC_Py
5252

53-
Some test modules also support direct invocation,
53+
Some test modules also support direct invocation,
5454
which might be useful for IDEs and local debugging::
5555

5656
./python Lib/test/test_typing.py
5757

5858
But, there are several important notes:
5959

60-
1. This way of running tests exists only
60+
1. This way of running tests exists only
6161
for local developer needs and is discouraged for anything else
6262
2. Some modules do not support it at all. One example is``test_importlib``.
6363
In other words: if some module does not have ``unittest.main()``, then

0 commit comments

Comments
 (0)
0