Skip to content

Conversation

@him2him2
Copy link

Summary

Fix ~75 typos and grammar issues across 37 documentation files, covering how-to guides, reference docs, examples, explanations, changelog, and project root files.

Categories of fixes

  • Broken RST directives: .. note:.. note:: (missing colon breaks rendering)
  • Subject-verb agreement: "suites handles" → "suites handle", "provide" → "provides", etc.
  • Missing/incorrect articles: "In relatively large" → "In a relatively large", etc.
  • Incorrect prepositions: "compatible to" → "compatible with", "referencing to" → "referencing"
  • Wrong verb forms: "teared down" → "torn down", "lead to" → "led to", "convert" → "converting"
  • Duplicate/extra words: "to to do" → "to do", "daily at our daily" → "daily in our", extra spaces
  • Spelling errors: "termal" → "terminal", "specially" → "especially", "straight forward" → "straightforward"
  • Incorrect possessives: "It's functionality" → "Its functionality"
  • Wrong URL: changelog entry 13963 referenced pytest-dev/pytest instead of pytest-dev/pytest-xdist
  • Ordinal typo: "March 3th" → "March 3rd"
  • Other grammar: "allows to capture" → "allows capturing", "an warning" → "a warning"

Files changed

37 files across:

  • Project root: CONTRIBUTING.rst, RELEASING.rst
  • doc/en/: index.rst, deprecations.rst, backwards-compatibility.rst, historical-notes.rst, funcarg_compare.rst, sponsor.rst
  • doc/en/how-to/: assert.rst, cache.rst, capture-stdout-stderr.rst, capture-warnings.rst, doctest.rst, fixtures.rst, logging.rst, monkeypatch.rst, output.rst, skipping.rst, subtests.rst, writing_hook_functions.rst, writing_plugins.rst
  • doc/en/reference/: customize.rst, exit-codes.rst, fixtures.rst, reference.rst
  • doc/en/explanation/: ci.rst, flaky.rst, goodpractices.rst
  • doc/en/example/: attic.rst, customdirectory.rst, markers.rst, parametrize.rst, pythoncollection.rst, simple.rst
  • changelog/: README.rst, 12444.bugfix.rst, 13963.bugfix.rst

Notes

  • Auto-generated code output blocks (from regendoc) were intentionally left untouched
  • CODE_OF_CONDUCT.md was excluded as it uses the standard Contributor Covenant v1.4 template text

@psf-chronographer psf-chronographer bot added the bot:chronographer:provided (automation) changelog entry is part of PR label Feb 11, 2026
Fix typos, grammar errors, and broken RST directives found across
37 documentation files including how-to guides, reference docs,
examples, explanations, and project root files.

Notable fixes:
- Broken RST directives (``.. note:`` → ``.. note::``)
- Subject-verb agreement errors
- Missing/incorrect articles and prepositions
- Incorrect verb forms ("teared down" → "torn down")
- Duplicate words and extra spaces
- Wrong URL in changelog (pytest → pytest-xdist)
- Ordinal typo ("3th" → "3rd")
@him2him2 him2him2 force-pushed the fix-docs-typos-grammar branch from d330859 to 46c0adc Compare February 11, 2026 07:30
@@ -1,3 +1,3 @@
Fixed subtests running with `pytest-xdist <https://github.com/pytest-dev/pytest>`__ when their contexts contain objects that are not JSON-serializable.
Fixed subtests running with `pytest-xdist <https://github.com/pytest-dev/pytest-xdist>`__ when their contexts contain objects that are not JSON-serializable.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or we could just link the PyPI project page:

Suggested change
Fixed subtests running with `pytest-xdist <https://github.com/pytest-dev/pytest-xdist>`__ when their contexts contain objects that are not JSON-serializable.
Fixed subtests running with :pypi:`pytest-xdist` when their contexts contain objects that are not JSON-serializable.

@@ -0,0 +1 @@
Fixed ~75 typos and grammar issues across documentation, including broken RST directives, subject-verb agreement errors, missing articles, and incorrect prepositions.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this note is actually needed in the change log.

@webknjaz
Copy link
Member

@him2him2 please reveal the tooling used / how you automated this.

in our example from a `conftest plugin`_.

sidenote: the temporary directory used here are instances of
sidenote: the temporary directories used here are instances of
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does sidenote need fixing too?

* ``improvement``: improvement of existing functionality, usually without requiring user intervention (for example, new fields being written in ``--junit-xml``, improved colors in terminal, etc).
* ``bugfix``: fixes a bug.
* ``doc``: documentation improvement, like rewording an entire session or adding missing docs.
* ``doc``: documentation improvement, like rewording an entire section or adding missing docs.
Copy link
Member

@webknjaz webknjaz Feb 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

self note: 🤔 this might need to be updated in pip-tools / aio-libs / cheroot / ansible-pylibssh

The goal of testing in a CI pipeline is different from testing locally. Indeed,
you can quickly edit some code and run your tests again on your computer, but
it is not possible with CI pipeline. They run on a separate server and are
it is not possible with a CI pipeline. It runs on a separate server and is
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this might've been meant as plural in that sentence:

Suggested change
it is not possible with a CI pipeline. It runs on a separate server and is
it is not possible with CI pipelines. They run on a separate server and are

Plus this variant would make the patch more surgical.

.. note::

If you do not use an editable install and not use the ``src`` layout (``mypkg`` directly in the root
If you do not use an editable install and do not use the ``src`` layout (``mypkg`` directly in the root
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe not directly related but it's probably a good idea to reference https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/. Though, this is likely something to do in a follow-up.

raise ExceptionGroup("", (ValueError("foo")))
They both supply a method :meth:`pytest.RaisesGroup.matches` :meth:`pytest.RaisesExc.matches` if you want to do matching outside of using it as a contextmanager. This can be helpful when checking ``.__context__`` or ``.__cause__``.
They both supply a method :meth:`pytest.RaisesGroup.matches` :meth:`pytest.RaisesExc.matches` if you want to do matching outside of using it as a context manager. This can be helpful when checking ``.__context__`` or ``.__cause__``.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a good time to reference the term docs:

Suggested change
They both supply a method :meth:`pytest.RaisesGroup.matches` :meth:`pytest.RaisesExc.matches` if you want to do matching outside of using it as a context manager. This can be helpful when checking ``.__context__`` or ``.__cause__``.
They both supply a method :meth:`pytest.RaisesGroup.matches` :meth:`pytest.RaisesExc.matches` if you want to do matching outside of using it as a :external+python:std:ref:`context manager <context-managers>`. This can be helpful when checking ``.__context__`` or ``.__cause__``.

addopts = -p no:warnings
Or passing ``-p no:warnings`` in the command-line. This might be useful if your test suites handles warnings
Or passing ``-p no:warnings`` in the command-line. This might be useful if your test suites handle warnings
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you misjudged the original intent here:

Suggested change
Or passing ``-p no:warnings`` in the command-line. This might be useful if your test suites handle warnings
Or passing ``-p no:warnings`` in the command-line. This might be useful if your test suite handles warnings

@@ -217,7 +217,7 @@ option names are:

If you need to record the whole test suite logging calls to a file, you can pass
:option:`--log-file=/path/to/log/file`. This log file is opened in write mode by default which
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably need a comma here, right?

Suggested change
:option:`--log-file=/path/to/log/file`. This log file is opened in write mode by default which
:option:`--log-file=/path/to/log/file`. This log file is opened in write mode by default, which

If you need to record the whole test suite logging calls to a file, you can pass
:option:`--log-file=/path/to/log/file`. This log file is opened in write mode by default which
means that it will be overwritten at each run tests session.
means that it will be overwritten at each test run session.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a feeling that this was meant to be

Suggested change
means that it will be overwritten at each test run session.
means that it will be overwritten at each test session.

Need additional opinions, though.

def test_function(): ...
This is specially useful for xfailing tests that are crashing the interpreter and should be
This is especially useful for xfailing tests that are crashing the interpreter and should be
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like the intent was

Suggested change
This is especially useful for xfailing tests that are crashing the interpreter and should be
This is particularly useful for xfailing tests that are crashing the interpreter and should be

Opinions?

.. note::

If you would like to customize the exit code in some scenarios, specially when
If you would like to customize the exit code in some scenarios, especially when
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the author might've wanted to say

Suggested change
If you would like to customize the exit code in some scenarios, especially when
If you would like to customize the exit code in some scenarios, specifically when

Right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bot:chronographer:provided (automation) changelog entry is part of PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants