From 46c0adc3fa5534abd7d28d4b05179cfc57fd3a77 Mon Sep 17 00:00:00 2001 From: ron Date: Wed, 11 Feb 2026 02:21:11 -0500 Subject: [PATCH 1/3] doc: fix ~75 typos and grammar issues across documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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") --- CONTRIBUTING.rst | 16 ++++++++-------- RELEASING.rst | 2 +- changelog/12444.bugfix.rst | 2 +- changelog/13963.bugfix.rst | 2 +- changelog/14205.doc.rst | 1 + changelog/README.rst | 4 ++-- doc/en/backwards-compatibility.rst | 4 ++-- doc/en/deprecations.rst | 10 +++++----- doc/en/example/attic.rst | 2 +- doc/en/example/customdirectory.rst | 2 +- doc/en/example/markers.rst | 2 +- doc/en/example/parametrize.rst | 4 ++-- doc/en/example/pythoncollection.rst | 2 +- doc/en/example/simple.rst | 6 +++--- doc/en/explanation/ci.rst | 4 ++-- doc/en/explanation/flaky.rst | 2 +- doc/en/explanation/goodpractices.rst | 4 ++-- doc/en/funcarg_compare.rst | 8 ++++---- doc/en/historical-notes.rst | 2 +- doc/en/how-to/assert.rst | 2 +- doc/en/how-to/cache.rst | 2 +- doc/en/how-to/capture-stdout-stderr.rst | 4 ++-- doc/en/how-to/capture-warnings.rst | 2 +- doc/en/how-to/doctest.rst | 2 +- doc/en/how-to/fixtures.rst | 12 ++++++------ doc/en/how-to/logging.rst | 6 +++--- doc/en/how-to/monkeypatch.rst | 2 +- doc/en/how-to/output.rst | 2 +- doc/en/how-to/skipping.rst | 2 +- doc/en/how-to/subtests.rst | 2 +- doc/en/how-to/writing_hook_functions.rst | 2 +- doc/en/how-to/writing_plugins.rst | 2 +- doc/en/index.rst | 2 +- doc/en/reference/customize.rst | 6 +++--- doc/en/reference/exit-codes.rst | 2 +- doc/en/reference/fixtures.rst | 10 +++++----- doc/en/reference/reference.rst | 9 ++++----- doc/en/sponsor.rst | 4 ++-- 38 files changed, 77 insertions(+), 77 deletions(-) create mode 100644 changelog/14205.doc.rst diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index 86d4231fedf..daf7f157cf8 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -146,7 +146,7 @@ the following: - PyPI presence with packaging metadata that contains a ``pytest-`` prefixed name, version number, authors, short and long description. -- a `tox configuration `_ +- a `tox configuration `_ for running tests using `tox `_. - a ``README`` describing how to use the plugin and on which @@ -280,7 +280,7 @@ Here is a simple overview, with pytest-specific bits: #. You can now edit your local working copy and run the tests again as necessary. Please follow `PEP-8 `_ for naming. You can pass different options to ``tox``. For example, to run tests on Python 3.13 and pass options to pytest - (e.g. enter pdb on failure) to pytest you can do:: + (e.g. enter pdb on failure) you can do:: $ tox -e py313 -- --pdb @@ -346,7 +346,7 @@ For example, to ensure a simple test passes you can write: result.assert_outcomes(failed=0, passed=1) -Alternatively, it is possible to make checks based on the actual output of the termal using +Alternatively, it is possible to make checks based on the actual output of the terminal using *glob-like* expressions: .. code-block:: python @@ -479,9 +479,9 @@ above? to do the backport. 2. However, often the merge is done by another maintainer, in which case it is nice of them to do the backport procedure if they have the time. -3. For bugs submitted by non-maintainers, it is expected that a core developer will to do +3. For bugs submitted by non-maintainers, it is expected that a core developer will do the backport, normally the one that merged the PR on ``main``. -4. If a non-maintainers notices a bug which is fixed on ``main`` but has not been backported +4. If a non-maintainer notices a bug which is fixed on ``main`` but has not been backported (due to maintainers forgetting to apply the *needs backport* label, or just plain missing it), they are also welcome to open a PR with the backport. The procedure is simple and really helps with the maintenance of the project. @@ -512,7 +512,7 @@ can always reopen the issue/pull request in their own time later if it makes sen When to close ~~~~~~~~~~~~~ -Here are a few general rules the maintainers use deciding when to close issues/PRs because +Here are a few general rules the maintainers use when deciding when to close issues/PRs because of lack of inactivity: * Issues labeled ``question`` or ``needs information``: closed after 14 days inactive. @@ -524,7 +524,7 @@ The above are **not hard rules**, but merely **guidelines**, and can be (and oft Closing pull requests ~~~~~~~~~~~~~~~~~~~~~ -When closing a Pull Request, it needs to be acknowledging the time, effort, and interest demonstrated by the person which submitted it. As mentioned previously, it is not the intent of the team to dismiss a stalled pull request entirely but to merely to clear up our queue, so a message like the one below is warranted when closing a pull request that went stale: +When closing a Pull Request, it needs to acknowledge the time, effort, and interest demonstrated by the person who submitted it. As mentioned previously, it is not the intent of the team to dismiss a stalled pull request entirely but to merely to clear up our queue, so a message like the one below is warranted when closing a pull request that went stale: Hi , @@ -532,7 +532,7 @@ When closing a Pull Request, it needs to be acknowledging the time, effort, and We noticed it has been awhile since you have updated this PR, however. pytest is a high activity project, with many issues/PRs being opened daily, so it is hard for us maintainers to track which PRs are ready for merging, for review, or need more attention. - So for those reasons we, think it is best to close the PR for now, but with the only intention to clean up our queue, it is by no means a rejection of your changes. We still encourage you to re-open this PR (it is just a click of a button away) when you are ready to get back to it. + So for those reasons, we think it is best to close the PR for now, but with the only intention to clean up our queue, it is by no means a rejection of your changes. We still encourage you to re-open this PR (it is just a click of a button away) when you are ready to get back to it. Again we appreciate your time for working on this, and hope you might get back to this at a later time! diff --git a/RELEASING.rst b/RELEASING.rst index 5723fe197c2..b819bfa3cc0 100644 --- a/RELEASING.rst +++ b/RELEASING.rst @@ -117,7 +117,7 @@ To release a version ``MAJOR.MINOR.PATCH``, follow these steps: #. Create a branch ``release-MAJOR.MINOR.PATCH`` from the ``MAJOR.MINOR.x`` branch. - Ensure your are updated and in a clean working tree. + Ensure you are updated and in a clean working tree. #. Using ``tox``, generate docs, changelog, announcements:: diff --git a/changelog/12444.bugfix.rst b/changelog/12444.bugfix.rst index 146cfc7ab24..ef8a2167426 100644 --- a/changelog/12444.bugfix.rst +++ b/changelog/12444.bugfix.rst @@ -1 +1 @@ -Fixed :func:`pytest.approx` which now correctly takes account Mapping keys order to compare them. +Fixed :func:`pytest.approx` which now correctly takes into account Mapping keys order to compare them. diff --git a/changelog/13963.bugfix.rst b/changelog/13963.bugfix.rst index a5f7ebe5c03..19d2740ad29 100644 --- a/changelog/13963.bugfix.rst +++ b/changelog/13963.bugfix.rst @@ -1,3 +1,3 @@ -Fixed subtests running with `pytest-xdist `__ when their contexts contain objects that are not JSON-serializable. +Fixed subtests running with `pytest-xdist `__ when their contexts contain objects that are not JSON-serializable. Fixes `pytest-dev/pytest-xdist#1273 `__. diff --git a/changelog/14205.doc.rst b/changelog/14205.doc.rst new file mode 100644 index 00000000000..0b28a929cf4 --- /dev/null +++ b/changelog/14205.doc.rst @@ -0,0 +1 @@ +Fixed ~75 typos and grammar issues across documentation, including broken RST directives, subject-verb agreement errors, missing articles, and incorrect prepositions. diff --git a/changelog/README.rst b/changelog/README.rst index fdaa573d427..f1ba2cbd0bd 100644 --- a/changelog/README.rst +++ b/changelog/README.rst @@ -16,12 +16,12 @@ Each file should be named like ``..rst``, where * ``feature``: new user facing features, like new command-line options and new behavior. * ``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. * ``deprecation``: feature deprecation. * ``breaking``: a change which may break existing suites, such as feature removal or behavior change. * ``vendor``: changes in packages vendored in pytest. * ``packaging``: notes for downstreams about unobvious side effects - and tooling. changes in the test invocation considerations and + and tooling. Changes in the test invocation considerations and runtime assumptions. * ``contrib``: stuff that affects the contributor experience. e.g. Running tests, building the docs, setting up the development diff --git a/doc/en/backwards-compatibility.rst b/doc/en/backwards-compatibility.rst index b62046ae2ac..a7ee2253d67 100644 --- a/doc/en/backwards-compatibility.rst +++ b/doc/en/backwards-compatibility.rst @@ -53,8 +53,8 @@ History ========= -Focus primary on smooth transition - stance (pre 6.0) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Focus primarily on smooth transition - stance (pre 6.0) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Keeping backwards compatibility has a very high priority in the pytest project. Although we have deprecated functionality over the years, most of it is still supported. All deprecations in pytest were done because simpler or more efficient ways of accomplishing the same tasks have emerged, making the old way of doing things unnecessary. diff --git a/doc/en/deprecations.rst b/doc/en/deprecations.rst index e607b7f26dc..ce7a5f2bae9 100644 --- a/doc/en/deprecations.rst +++ b/doc/en/deprecations.rst @@ -90,7 +90,7 @@ Example of problematic code: def test_2(self, n): pass -You can fix it by convert generators and iterators to lists or tuples: +You can fix it by converting generators and iterators to lists or tuples: .. code-block:: python @@ -167,7 +167,7 @@ In ``8.2`` the ``exc_type`` parameter has been added, giving users the ability o to skip tests only if the module cannot really be found, and not because of some other error. Catching only :class:`ModuleNotFoundError` by default (and letting other errors propagate) would be the best solution, -however for backward compatibility, pytest will keep the existing behavior but raise an warning if: +however for backward compatibility, pytest will keep the existing behavior but raise a warning if: 1. The captured exception is of type :class:`ImportError`, and: 2. The user does not pass ``exc_type`` explicitly. @@ -342,7 +342,7 @@ The ``yield_fixture`` function/decorator ``pytest.yield_fixture`` is a deprecated alias for :func:`pytest.fixture`. -It has been so for a very long time, so can be search/replaced safely. +It has been so for a very long time, so it can be search/replaced safely. Removed Features and Breaking Changes @@ -876,7 +876,7 @@ The ``pytest._fillfuncargs`` function This function was kept for backward compatibility with an older plugin. -It's functionality is not meant to be used directly, but if you must replace +Its functionality is not meant to be used directly, but if you must replace it, use `function._request._fillfixtures()` instead, though note this is not a public API and may break in the future. @@ -907,7 +907,7 @@ The ``--result-log`` option produces a stream of test reports which can be analysed at runtime, but it uses a custom format which requires users to implement their own parser. -The `pytest-reportlog `__ plugin provides a ``--report-log`` option, a more standard and extensible alternative, producing +The `pytest-reportlog `__ plugin provides a ``--report-log`` option, a more standard and extensible alternative, producing one JSON object per-line, and should cover the same use cases. Please try it out and provide feedback. The ``pytest-reportlog`` plugin might even be merged into the core diff --git a/doc/en/example/attic.rst b/doc/en/example/attic.rst index 2b1f2766dce..f420963420a 100644 --- a/doc/en/example/attic.rst +++ b/doc/en/example/attic.rst @@ -75,7 +75,7 @@ decorate its result. This mechanism allows us to stay ignorant of how/where the function argument is provided - 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 the `py.path.local`_ class which provides many of the os.path methods in a convenient way. diff --git a/doc/en/example/customdirectory.rst b/doc/en/example/customdirectory.rst index 6e326352a7e..705a3373654 100644 --- a/doc/en/example/customdirectory.rst +++ b/doc/en/example/customdirectory.rst @@ -36,7 +36,7 @@ You can create a ``manifest.json`` file and some test files: .. include:: customdirectory/tests/test_third.py :literal: -An you can now execute the test specification: +And you can now execute the test specification: .. code-block:: pytest diff --git a/doc/en/example/markers.rst b/doc/en/example/markers.rst index 4f6738207e1..c8e4172a696 100644 --- a/doc/en/example/markers.rst +++ b/doc/en/example/markers.rst @@ -411,7 +411,7 @@ A test file using this local plugin: def test_basic_db_operation(): pass -and an example invocations specifying a different environment than what +and an example invocation specifying a different environment than what the test needs: .. code-block:: pytest diff --git a/doc/en/example/parametrize.rst b/doc/en/example/parametrize.rst index 7aec1364953..b25b822618a 100644 --- a/doc/en/example/parametrize.rst +++ b/doc/en/example/parametrize.rst @@ -4,7 +4,7 @@ Parametrizing tests ================================================= -``pytest`` allows to easily parametrize test functions. +``pytest`` allows you to easily parametrize test functions. For basic docs, see :ref:`parametrize-basics`. In the following we provide some examples using @@ -642,7 +642,7 @@ As the result: - Four tests were collected - One test was deselected because it doesn't have the ``basic`` mark. -- Three tests with the ``basic`` mark was selected. +- Three tests with the ``basic`` mark were selected. - The test ``test_eval[1+7-8]`` passed, but the name is autogenerated and confusing. - The test ``test_eval[basic_2+4]`` passed. - The test ``test_eval[basic_6*9]`` was expected to fail and did fail. diff --git a/doc/en/example/pythoncollection.rst b/doc/en/example/pythoncollection.rst index 339944c4758..26fdb68b08f 100644 --- a/doc/en/example/pythoncollection.rst +++ b/doc/en/example/pythoncollection.rst @@ -161,7 +161,7 @@ You can check for multiple glob patterns by adding a space between the patterns: .. note:: - the ``python_functions`` and ``python_classes`` options has no effect + the ``python_functions`` and ``python_classes`` options have no effect for ``unittest.TestCase`` test discovery because pytest delegates discovery of test case methods to unittest code. diff --git a/doc/en/example/simple.rst b/doc/en/example/simple.rst index 0640160e3bb..a07927280ae 100644 --- a/doc/en/example/simple.rst +++ b/doc/en/example/simple.rst @@ -416,10 +416,10 @@ running from a test you can do this: if os.environ.get("PYTEST_VERSION") is not None: - # Things you want to to do if your code is called by pytest. + # Things you want to do if your code is called by pytest. ... else: - # Things you want to to do if your code is not called by pytest. + # Things you want to do if your code is not called by pytest. ... @@ -773,7 +773,7 @@ The two test modules in the ``a`` directory see the same ``db`` fixture instance while the one test in the sister-directory ``b`` doesn't see it. We could of course also define a ``db`` fixture in that sister directory's ``conftest.py`` file. Note that each fixture is only instantiated if there is a test actually needing -it (unless you use "autouse" fixture which are always executed ahead of the first test +it (unless you use "autouse" fixtures which are always executed ahead of the first test executing). diff --git a/doc/en/explanation/ci.rst b/doc/en/explanation/ci.rst index 6f6734f395b..1e062a07e1c 100644 --- a/doc/en/explanation/ci.rst +++ b/doc/en/explanation/ci.rst @@ -8,7 +8,7 @@ Rationale 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 triggered by specific actions. From that observation, pytest can detect when it is in a CI environment and @@ -17,7 +17,7 @@ adapt some of its behaviours. How CI is detected ------------------ -Pytest knows it is in a CI environment when either one of these environment variables are set to a non-empty value: +Pytest knows it is in a CI environment when either one of these environment variables is set to a non-empty value: * `CI`: used by many CI systems. * `BUILD_NUMBER`: used by Jenkins. diff --git a/doc/en/explanation/flaky.rst b/doc/en/explanation/flaky.rst index 8369e1d9311..918d6f10b36 100644 --- a/doc/en/explanation/flaky.rst +++ b/doc/en/explanation/flaky.rst @@ -42,7 +42,7 @@ It is of course possible (and common) for tests and fixtures to spawn threads th * Make sure to eventually wait on any spawned threads -- for example at the end of a test, or during the teardown of a fixture. * Avoid using primitives provided by pytest (:func:`pytest.warns`, :func:`pytest.raises`, etc) from multiple threads, as they are not thread-safe. -If your test suite uses threads and your are seeing flaky test results, do not discount the possibility that the test is implicitly using global state in pytest itself. +If your test suite uses threads and you are seeing flaky test results, do not discount the possibility that the test is implicitly using global state in pytest itself. Related features ^^^^^^^^^^^^^^^^ diff --git a/doc/en/explanation/goodpractices.rst b/doc/en/explanation/goodpractices.rst index 7c589b57033..fb12f890ead 100644 --- a/doc/en/explanation/goodpractices.rst +++ b/doc/en/explanation/goodpractices.rst @@ -143,7 +143,7 @@ which are better explained in this excellent `blog post`_ by Ionel Cristian Măr .. 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 directory) you can rely on the fact that Python by default puts the current directory in ``sys.path`` to import your package and run ``python -m pytest`` to execute the tests against the local copy directly. @@ -376,7 +376,7 @@ If you don't want to automatically pick up new options, you can enable options i strict_parametrization_ids = true strict_xfail = true -If you want to use strict mode but having trouble with a specific option, you can turn it off individually: +If you want to use strict mode but are having trouble with a specific option, you can turn it off individually: .. tab:: toml diff --git a/doc/en/funcarg_compare.rst b/doc/en/funcarg_compare.rst index bc5e7d3c515..7cd4c0f1676 100644 --- a/doc/en/funcarg_compare.rst +++ b/doc/en/funcarg_compare.rst @@ -18,7 +18,7 @@ The pre pytest-2.3 funcarg mechanism calls a factory each time a funcarg for a test function is required. If a factory wants to reuse a resource across different scopes, it often used the ``request.cached_setup()`` helper to manage caching of -resources. Here is a basic example how we could implement +resources. Here is a basic example of how we could implement a per-session Database object: .. code-block:: python @@ -39,10 +39,10 @@ a per-session Database object: There are several limitations and difficulties with this approach: -1. Scoping funcarg resource creation is not straight forward, instead one must +1. Scoping funcarg resource creation is not straightforward, instead one must understand the intricate cached_setup() method mechanics. -2. parametrizing the "db" resource is not straight forward: +2. parametrizing the "db" resource is not straightforward: you need to apply a "parametrize" decorator or implement a :hook:`pytest_generate_tests` hook calling :py:func:`~pytest.Metafunc.parametrize` which @@ -55,7 +55,7 @@ There are several limitations and difficulties with this approach: at the same time, making it hard for them to affect global state of the application under test. -4. there is no way how you can make use of funcarg factories +4. there is no way you can make use of funcarg factories in xUnit setup methods. 5. A non-parametrized fixture function cannot use a parametrized diff --git a/doc/en/historical-notes.rst b/doc/en/historical-notes.rst index be67036d6ca..600aed4c17b 100644 --- a/doc/en/historical-notes.rst +++ b/doc/en/historical-notes.rst @@ -304,7 +304,7 @@ For more details see :ref:`breakpoints`. -Access of ``Module``, ``Function``, ``Class``, ``Instance``, ``File`` and ``Item`` through ``Node`` instances have long +Access of ``Module``, ``Function``, ``Class``, ``Instance``, ``File`` and ``Item`` through ``Node`` instances has long been documented as deprecated, but started to emit warnings from pytest ``3.9`` and onward. Users should just ``import pytest`` and access those objects using the ``pytest`` module. diff --git a/doc/en/how-to/assert.rst b/doc/en/how-to/assert.rst index 4ef2664b1d5..6627611c4e9 100644 --- a/doc/en/how-to/assert.rst +++ b/doc/en/how-to/assert.rst @@ -218,7 +218,7 @@ To specify more details about the contained exception you can use :class:`pytest with pytest.RaisesGroup(pytest.RaisesExc(ValueError, match="foo")): 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__``. .. code-block:: python diff --git a/doc/en/how-to/cache.rst b/doc/en/how-to/cache.rst index 4271ab469dc..ca345916fc5 100644 --- a/doc/en/how-to/cache.rst +++ b/doc/en/how-to/cache.rst @@ -33,7 +33,7 @@ Other plugins may access the `config.cache`_ object to set/get Rerunning only failures or failures first ----------------------------------------------- -First, let's create 50 test invocation of which only 2 fail: +First, let's create 50 test invocations of which only 2 fail: .. code-block:: python diff --git a/doc/en/how-to/capture-stdout-stderr.rst b/doc/en/how-to/capture-stdout-stderr.rst index 8a6a42d4134..5de89bc0e3f 100644 --- a/doc/en/how-to/capture-stdout-stderr.rst +++ b/doc/en/how-to/capture-stdout-stderr.rst @@ -6,7 +6,7 @@ How to capture stdout/stderr output Pytest intercepts stdout and stderr as configured by the :option:`--capture=` command-line argument or by using fixtures. The ``--capture=`` flag configures -reporting, whereas the fixtures offer more granular control and allows +reporting, whereas the fixtures offer more granular control and allow inspection of output during testing. The reports can be customized with the :option:`-r` flag. @@ -23,7 +23,7 @@ fail on attempts to read from it because it is rarely desired to wait for interactive input when running automated tests. By default capturing is done by intercepting writes to low level -file descriptors. This allows to capture output from simple +file descriptors. This allows capturing output from simple print statements as well as output from a subprocess started by a test. diff --git a/doc/en/how-to/capture-warnings.rst b/doc/en/how-to/capture-warnings.rst index ae9e71a2750..e106bfd961d 100644 --- a/doc/en/how-to/capture-warnings.rst +++ b/doc/en/how-to/capture-warnings.rst @@ -220,7 +220,7 @@ This plugin is enabled by default but can be disabled entirely in your configura [pytest] 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 using an external system. diff --git a/doc/en/how-to/doctest.rst b/doc/en/how-to/doctest.rst index 433b35b61ce..59d1033ed4f 100644 --- a/doc/en/how-to/doctest.rst +++ b/doc/en/how-to/doctest.rst @@ -185,7 +185,7 @@ Output format ------------- You can change the diff output format on failure for your doctests -by using one of standard doctest modules format in options +by using one of the standard doctest module's format options (see :data:`python:doctest.REPORT_UDIFF`, :data:`python:doctest.REPORT_CDIFF`, :data:`python:doctest.REPORT_NDIFF`, :data:`python:doctest.REPORT_ONLY_FIRST_FAILURE`): diff --git a/doc/en/how-to/fixtures.rst b/doc/en/how-to/fixtures.rst index 14949994598..991256e7473 100644 --- a/doc/en/how-to/fixtures.rst +++ b/doc/en/how-to/fixtures.rst @@ -471,7 +471,7 @@ marked ``smtp_connection`` fixture function. Running the test looks like this: ============================ 2 failed in 0.12s ============================= You see the two ``assert 0`` failing and more importantly you can also see -that the **exactly same** ``smtp_connection`` object was passed into the +that the **exact same** ``smtp_connection`` object was passed into the two test functions because pytest shows the incoming argument values in the traceback. As a result, the two test functions using ``smtp_connection`` run as quick as a single one because they reuse the same instance. @@ -1645,7 +1645,7 @@ Let's run the tests in verbose mode and with looking at the print-output: ============================ 8 passed in 0.12s ============================= You can see that the parametrized module-scoped ``modarg`` resource caused an -ordering of test execution that lead to the fewest possible "active" resources. +ordering of test execution that led to the fewest possible "active" resources. The finalizer for the ``mod1`` parametrized resource was executed before the ``mod2`` resource was setup. @@ -1654,7 +1654,7 @@ Then test_1 is executed with ``mod1``, then test_2 with ``mod1``, then test_1 with ``mod2`` and finally test_2 with ``mod2``. The ``otherarg`` parametrized resource (having function scope) was set up before -and teared down after every test that used it. +and torn down after every test that used it. .. _`usefixtures`: @@ -1760,7 +1760,7 @@ into a configuration file: Overriding fixtures on various levels ------------------------------------- -In relatively large test suite, you may want to *override* a fixture, to augment +In a relatively large test suite, you may want to *override* a fixture, to augment or change its behavior inside of certain test modules or directories. Override a fixture on a directory (conftest) level @@ -1798,7 +1798,7 @@ Given the tests file structure is: def test_username(username): assert username == 'overridden-username' -As you can see, a fixture with the same name can be overridden for certain test directory level. +As you can see, a fixture with the same name can be overridden for a certain test directory level. Note that the ``base`` or ``super`` fixture can be accessed from the ``overriding`` fixture easily - used in the example above. @@ -1840,7 +1840,7 @@ Given the tests file structure is: def test_username(username): assert username == 'overridden-else-username' -In the example above, a fixture with the same name can be overridden for certain test module. +In the example above, a fixture with the same name can be overridden for a certain test module. Override a fixture with direct test parametrization diff --git a/doc/en/how-to/logging.rst b/doc/en/how-to/logging.rst index c0762e60928..1665e88586f 100644 --- a/doc/en/how-to/logging.rst +++ b/doc/en/how-to/logging.rst @@ -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 -means that it will be overwritten at each run tests session. +means that it will be overwritten at each test run session. If you'd like the file opened in append mode instead, then you can pass :option:`--log-file-mode=a`. Note that relative paths for the log-file location, whether passed on the CLI or declared in a config file, are always resolved relative to the current working directory. @@ -312,7 +312,7 @@ made in ``3.4`` after community feedback: * :ref:`Live Logs ` are now sent to ``sys.stdout`` and no longer require the :option:`-s` command-line option to work. -If you want to partially restore the logging behavior of version ``3.3``, you can add this options to your configuration +If you want to partially restore the logging behavior of version ``3.3``, you can add these options to your configuration file: .. tab:: toml @@ -331,4 +331,4 @@ file: log_cli = true log_level = NOTSET -More details about the discussion that lead to this changes can be read in :issue:`3013`. +More details about the discussion that led to these changes can be read in :issue:`3013`. diff --git a/doc/en/how-to/monkeypatch.rst b/doc/en/how-to/monkeypatch.rst index ad0c6e0e1c5..7442a85c10e 100644 --- a/doc/en/how-to/monkeypatch.rst +++ b/doc/en/how-to/monkeypatch.rst @@ -382,7 +382,7 @@ You can use the :py:meth:`monkeypatch.delitem ` to remove v def test_missing_user(monkeypatch): - # patch the DEFAULT_CONFIG t be missing the 'user' key + # patch the DEFAULT_CONFIG to be missing the 'user' key monkeypatch.delitem(app.DEFAULT_CONFIG, "user", raising=False) # Key error expected because a config is not passed, and the diff --git a/doc/en/how-to/output.rst b/doc/en/how-to/output.rst index d92b2131701..a594fcb3aab 100644 --- a/doc/en/how-to/output.rst +++ b/doc/en/how-to/output.rst @@ -771,7 +771,7 @@ record_testsuite_property .. versionadded:: 4.5 -If you want to add a properties node at the test-suite level, which may contains properties +If you want to add a properties node at the test-suite level, which may contain properties that are relevant to all tests, you can use the ``record_testsuite_property`` session-scoped fixture: The ``record_testsuite_property`` session-scoped fixture can be used to add properties relevant diff --git a/doc/en/how-to/skipping.rst b/doc/en/how-to/skipping.rst index 3b4d412843d..8cebab93c23 100644 --- a/doc/en/how-to/skipping.rst +++ b/doc/en/how-to/skipping.rst @@ -311,7 +311,7 @@ even executed, use the ``run`` parameter as ``False``: @pytest.mark.xfail(run=False) 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 investigated later. .. _`xfail strict tutorial`: diff --git a/doc/en/how-to/subtests.rst b/doc/en/how-to/subtests.rst index 5a08dbc4769..93b9d052afd 100644 --- a/doc/en/how-to/subtests.rst +++ b/doc/en/how-to/subtests.rst @@ -136,4 +136,4 @@ Subtests This feature was originally implemented as a separate plugin in `pytest-subtests `__, but since ``9.0`` has been merged into the core. - The core implementation should be compatible to the plugin implementation, except it does not contain custom command-line options to control subtest output. + The core implementation should be compatible with the plugin implementation, except it does not contain custom command-line options to control subtest output. diff --git a/doc/en/how-to/writing_hook_functions.rst b/doc/en/how-to/writing_hook_functions.rst index cd18301ce84..d5d6d2ae4f7 100644 --- a/doc/en/how-to/writing_hook_functions.rst +++ b/doc/en/how-to/writing_hook_functions.rst @@ -94,7 +94,7 @@ around the actual hook implementations, in which case it can return the result value of the ``yield``. The simplest (though useless) hook wrapper is ``return (yield)``. -In other cases, the wrapper wants the adjust or adapt the result, in which case +In other cases, the wrapper wants to adjust or adapt the result, in which case it can return a new value. If the result of the underlying hook is a mutable object, the wrapper may modify that result, but it's probably better to avoid it. diff --git a/doc/en/how-to/writing_plugins.rst b/doc/en/how-to/writing_plugins.rst index 6b7e2a7e496..56043a14f97 100644 --- a/doc/en/how-to/writing_plugins.rst +++ b/doc/en/how-to/writing_plugins.rst @@ -48,7 +48,7 @@ Plugin discovery order at tool startup 5. by loading all plugins specified through the :envvar:`PYTEST_PLUGINS` environment variable. -6. by loading all "initial ":file:`conftest.py` files: +6. by loading all "initial" :file:`conftest.py` files: - determine the test paths: specified on the command line, otherwise in :confval:`testpaths` if defined and running from the rootdir, otherwise the diff --git a/doc/en/index.rst b/doc/en/index.rst index 77b502e3e41..fa05b3a0c48 100644 --- a/doc/en/index.rst +++ b/doc/en/index.rst @@ -2,7 +2,7 @@ .. sidebar:: **Next Open Trainings and Events** - - `Professional Testing with Python `_, via `Python Academy `_ (3 day in-depth training), **March 3th -- 5th 2026**, Remote + - `Professional Testing with Python `_, via `Python Academy `_ (3 day in-depth training), **March 3rd -- 5th 2026**, Remote Also see :doc:`previous talks and blogposts ` diff --git a/doc/en/reference/customize.rst b/doc/en/reference/customize.rst index 9b954bdcab1..54cf86d2e3d 100644 --- a/doc/en/reference/customize.rst +++ b/doc/en/reference/customize.rst @@ -160,7 +160,7 @@ the command line arguments (specified test files, paths) and on the existence of configuration files. The determined ``rootdir`` and ``configfile`` are printed as part of the pytest header during startup. -Here's a summary what ``pytest`` uses ``rootdir`` for: +Here's a summary of what ``pytest`` uses ``rootdir`` for: * Construct *nodeids* during collection; each test is assigned a unique *nodeid* which is rooted at the ``rootdir`` and takes into account @@ -204,7 +204,7 @@ Here is the algorithm which finds the rootdir from ``args``: directory. This allows the use of pytest in structures that are not part of a package and don't have any particular configuration file. -If no ``args`` are given, pytest collects test below the current working +If no ``args`` are given, pytest collects tests below the current working directory and also starts determining the ``rootdir`` from there. Files will only be matched for configuration if: @@ -274,7 +274,7 @@ check for configuration files as follows: ``pytest --log-output ../../test.log args``. Then ``args`` is mandatory, otherwise pytest uses the directory of test.log for rootdir determination (see also :issue:`1435`). - A dot ``.`` for referencing to the current working directory is also + A dot ``.`` for referencing the current working directory is also possible. diff --git a/doc/en/reference/exit-codes.rst b/doc/en/reference/exit-codes.rst index b695ca3702e..3ea29015dee 100644 --- a/doc/en/reference/exit-codes.rst +++ b/doc/en/reference/exit-codes.rst @@ -20,7 +20,7 @@ They are represented by the :class:`pytest.ExitCode` enum. The exit codes being .. 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 no tests are collected, consider using the `pytest-custom_exit_code `__ plugin. diff --git a/doc/en/reference/fixtures.rst b/doc/en/reference/fixtures.rst index b0fa8660f9b..c4a8d01ff0e 100644 --- a/doc/en/reference/fixtures.rst +++ b/doc/en/reference/fixtures.rst @@ -277,10 +277,10 @@ the test's search for fixtures would look like: pytest will only search for ``a_fix`` and ``b_fix`` in the plugins after searching for them first in the scopes inside ``tests/``. -.. note: +.. note:: pytest can tell you what fixtures are available for a given test if you call - ``pytests`` along with the test's name (or the scope it's in), and provide + ``pytest`` along with the test's name (or the scope it's in), and provide the :option:`--fixtures` flag, e.g. ``pytest --fixtures test_something.py`` (fixtures with names that start with ``_`` will only be shown if you also provide the :option:`-v` flag). @@ -354,7 +354,7 @@ an order of operations for a given test. If there's any ambiguity, and the order of operations can be interpreted more than one way, you should assume pytest could go with any one of those interpretations at any point. -For example, if ``d`` didn't request ``c``, i.e.the graph would look like this: +For example, if ``d`` didn't request ``c``, i.e. the graph would look like this: .. image:: /example/fixtures/test_fixtures_order_dependencies_unclear.* :align: center @@ -448,10 +448,10 @@ for the tests inside ``TestClassWithoutAutouse``, since they can reference can't see ``c3``. -.. note: +.. note:: pytest can tell you what order the fixtures will execute in for a given test - if you call ``pytests`` along with the test's name (or the scope it's in), + if you call ``pytest`` along with the test's name (or the scope it's in), and provide the :option:`--setup-plan` flag, e.g. ``pytest --setup-plan test_something.py`` (fixtures with names that start with ``_`` will only be shown if you also provide the :option:`-v` flag). diff --git a/doc/en/reference/reference.rst b/doc/en/reference/reference.rst index 62ae3564e18..a2f7a13de12 100644 --- a/doc/en/reference/reference.rst +++ b/doc/en/reference/reference.rst @@ -1179,11 +1179,11 @@ Environment variables that can be used to change pytest's behavior. .. envvar:: CI -When set to a non-empty value, pytest acknowledges that is running in a CI process. See also :ref:`ci-pipelines`. +When set to a non-empty value, pytest acknowledges that it is running in a CI process. See also :ref:`ci-pipelines`. .. envvar:: BUILD_NUMBER -When set to a non-empty value, pytest acknowledges that is running in a CI process. Alternative to :envvar:`CI`. See also :ref:`ci-pipelines`. +When set to a non-empty value, pytest acknowledges that it is running in a CI process. Alternative to :envvar:`CI`. See also :ref:`ci-pipelines`. .. envvar:: PYTEST_ADDOPTS @@ -1315,7 +1315,7 @@ Configuration Options Here is a list of builtin configuration options that may be written in a ``pytest.ini`` (or ``.pytest.ini``), ``pyproject.toml``, ``tox.ini``, or ``setup.cfg`` file, usually located at the root of your repository. -To see each file format in details, see :ref:`config file formats`. +To see each file format in detail, see :ref:`config file formats`. .. warning:: Usage of ``setup.cfg`` is not recommended except for very simple use cases. ``.cfg`` @@ -1586,7 +1586,6 @@ passed multiple times. The expected format is ``name=value``. For example:: faulthandler_timeout = 5 For more information please refer to :ref:`faulthandler`. - For more information please refer to :ref:`faulthandler`. .. confval:: filterwarnings @@ -3180,7 +3179,7 @@ See :ref:`logging` for a guide on using these flags. .. option:: --log-file=PATH - Path to a file when logging will be written to. + Path to a file where logging will be written to. .. option:: --log-file-mode diff --git a/doc/en/sponsor.rst b/doc/en/sponsor.rst index 8362a7f0a3a..6ad722be94c 100644 --- a/doc/en/sponsor.rst +++ b/doc/en/sponsor.rst @@ -2,7 +2,7 @@ Sponsor ======= pytest is maintained by a team of volunteers from all around the world in their free time. While -we work on pytest because we love the project and use it daily at our daily jobs, monetary +we work on pytest because we love the project and use it daily in our jobs, monetary compensation when possible is welcome to justify time away from friends, family and personal time. Money is also used to fund local sprints, merchandising (stickers to distribute in conferences for example) @@ -12,7 +12,7 @@ OpenCollective -------------- `Open Collective`_ is an online funding platform for open and transparent communities. -It provide tools to raise money and share your finances in full transparency. +It provides tools to raise money and share your finances in full transparency. It is the platform of choice for individuals and companies that want to make one-time or monthly donations directly to the project. From 2c5250d70f994fe5e5ed57735e1b1a81cc8c9b58 Mon Sep 17 00:00:00 2001 From: ron Date: Wed, 11 Feb 2026 08:32:51 -0500 Subject: [PATCH 2/3] doc: address reviewer feedback from @webknjaz MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Apply suggestions from PR review: - changelog/13963.bugfix.rst: use :pypi: role instead of raw URL - changelog/14205.doc.rst: remove unnecessary changelog entry - doc/en/example/attic.rst: "sidenote" → "Side note" - doc/en/explanation/ci.rst: keep plural "CI pipelines. They run...are" - doc/en/how-to/assert.rst: cross-reference "context manager" to Python docs - doc/en/how-to/capture-warnings.rst: singular "test suite handles" - doc/en/how-to/logging.rst: add missing comma, "each test session" - doc/en/how-to/skipping.rst: "particularly" instead of "especially" - doc/en/reference/exit-codes.rst: "specifically" instead of "especially" - doc/en/reference/reference.rst: drop "where" from log-file description - doc/en/deprecations.rst: "searched/replaced", use :pypi: role - RELEASING.rst: rephrase "Ensure your local checkout is up to date" - CONTRIBUTING.rst: "we should acknowledge", fix double-when, add backport label --- CONTRIBUTING.rst | 6 +++--- RELEASING.rst | 2 +- changelog/13963.bugfix.rst | 2 +- changelog/14205.doc.rst | 1 - doc/en/deprecations.rst | 4 ++-- doc/en/example/attic.rst | 2 +- doc/en/explanation/ci.rst | 2 +- doc/en/how-to/assert.rst | 2 +- doc/en/how-to/capture-warnings.rst | 2 +- doc/en/how-to/logging.rst | 4 ++-- doc/en/how-to/skipping.rst | 2 +- doc/en/reference/exit-codes.rst | 2 +- doc/en/reference/reference.rst | 2 +- 13 files changed, 16 insertions(+), 17 deletions(-) delete mode 100644 changelog/14205.doc.rst diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index daf7f157cf8..0f929162c65 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -482,7 +482,7 @@ above? 3. For bugs submitted by non-maintainers, it is expected that a core developer will do the backport, normally the one that merged the PR on ``main``. 4. If a non-maintainer notices a bug which is fixed on ``main`` but has not been backported - (due to maintainers forgetting to apply the *needs backport* label, or just plain missing it), + (due to maintainers forgetting to apply the *needs backport* or *backport x.x.x* labels, or just plain missing it), they are also welcome to open a PR with the backport. The procedure is simple and really helps with the maintenance of the project. @@ -512,7 +512,7 @@ can always reopen the issue/pull request in their own time later if it makes sen When to close ~~~~~~~~~~~~~ -Here are a few general rules the maintainers use when deciding when to close issues/PRs because +Here are a few general rules the maintainers use to decide when to close issues/PRs because of lack of inactivity: * Issues labeled ``question`` or ``needs information``: closed after 14 days inactive. @@ -524,7 +524,7 @@ The above are **not hard rules**, but merely **guidelines**, and can be (and oft Closing pull requests ~~~~~~~~~~~~~~~~~~~~~ -When closing a Pull Request, it needs to acknowledge the time, effort, and interest demonstrated by the person who submitted it. As mentioned previously, it is not the intent of the team to dismiss a stalled pull request entirely but to merely to clear up our queue, so a message like the one below is warranted when closing a pull request that went stale: +When closing a Pull Request, we should acknowledge the time, effort, and interest demonstrated by the person who submitted it. As mentioned previously, it is not the intent of the team to dismiss a stalled pull request entirely but to merely to clear up our queue, so a message like the one below is warranted when closing a pull request that went stale: Hi , diff --git a/RELEASING.rst b/RELEASING.rst index b819bfa3cc0..76929ef7043 100644 --- a/RELEASING.rst +++ b/RELEASING.rst @@ -117,7 +117,7 @@ To release a version ``MAJOR.MINOR.PATCH``, follow these steps: #. Create a branch ``release-MAJOR.MINOR.PATCH`` from the ``MAJOR.MINOR.x`` branch. - Ensure you are updated and in a clean working tree. + Ensure your local checkout is up to date and in a clean working tree. #. Using ``tox``, generate docs, changelog, announcements:: diff --git a/changelog/13963.bugfix.rst b/changelog/13963.bugfix.rst index 19d2740ad29..8717b265c72 100644 --- a/changelog/13963.bugfix.rst +++ b/changelog/13963.bugfix.rst @@ -1,3 +1,3 @@ -Fixed subtests running with `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. Fixes `pytest-dev/pytest-xdist#1273 `__. diff --git a/changelog/14205.doc.rst b/changelog/14205.doc.rst deleted file mode 100644 index 0b28a929cf4..00000000000 --- a/changelog/14205.doc.rst +++ /dev/null @@ -1 +0,0 @@ -Fixed ~75 typos and grammar issues across documentation, including broken RST directives, subject-verb agreement errors, missing articles, and incorrect prepositions. diff --git a/doc/en/deprecations.rst b/doc/en/deprecations.rst index ce7a5f2bae9..ea11696b47a 100644 --- a/doc/en/deprecations.rst +++ b/doc/en/deprecations.rst @@ -342,7 +342,7 @@ The ``yield_fixture`` function/decorator ``pytest.yield_fixture`` is a deprecated alias for :func:`pytest.fixture`. -It has been so for a very long time, so it can be search/replaced safely. +It has been so for a very long time, so it can be searched/replaced safely. Removed Features and Breaking Changes @@ -907,7 +907,7 @@ The ``--result-log`` option produces a stream of test reports which can be analysed at runtime, but it uses a custom format which requires users to implement their own parser. -The `pytest-reportlog `__ plugin provides a ``--report-log`` option, a more standard and extensible alternative, producing +The :pypi:`pytest-reportlog` plugin provides a ``--report-log`` option, a more standard and extensible alternative, producing one JSON object per-line, and should cover the same use cases. Please try it out and provide feedback. The ``pytest-reportlog`` plugin might even be merged into the core diff --git a/doc/en/example/attic.rst b/doc/en/example/attic.rst index f420963420a..3a2e228337e 100644 --- a/doc/en/example/attic.rst +++ b/doc/en/example/attic.rst @@ -75,7 +75,7 @@ decorate its result. This mechanism allows us to stay ignorant of how/where the function argument is provided - in our example from a `conftest plugin`_. -sidenote: the temporary directories used here are instances of +Side note: the temporary directories used here are instances of the `py.path.local`_ class which provides many of the os.path methods in a convenient way. diff --git a/doc/en/explanation/ci.rst b/doc/en/explanation/ci.rst index 1e062a07e1c..927c1075847 100644 --- a/doc/en/explanation/ci.rst +++ b/doc/en/explanation/ci.rst @@ -8,7 +8,7 @@ Rationale 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 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 triggered by specific actions. From that observation, pytest can detect when it is in a CI environment and diff --git a/doc/en/how-to/assert.rst b/doc/en/how-to/assert.rst index 6627611c4e9..f8144a08109 100644 --- a/doc/en/how-to/assert.rst +++ b/doc/en/how-to/assert.rst @@ -218,7 +218,7 @@ To specify more details about the contained exception you can use :class:`pytest with pytest.RaisesGroup(pytest.RaisesExc(ValueError, match="foo")): 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 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 `. This can be helpful when checking ``.__context__`` or ``.__cause__``. .. code-block:: python diff --git a/doc/en/how-to/capture-warnings.rst b/doc/en/how-to/capture-warnings.rst index e106bfd961d..02da2dd7669 100644 --- a/doc/en/how-to/capture-warnings.rst +++ b/doc/en/how-to/capture-warnings.rst @@ -220,7 +220,7 @@ This plugin is enabled by default but can be disabled entirely in your configura [pytest] addopts = -p no:warnings -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 using an external system. diff --git a/doc/en/how-to/logging.rst b/doc/en/how-to/logging.rst index 1665e88586f..25b4e9017e2 100644 --- a/doc/en/how-to/logging.rst +++ b/doc/en/how-to/logging.rst @@ -216,8 +216,8 @@ option names are: * :confval:`log_cli_date_format` 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 test run session. +: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 test session. If you'd like the file opened in append mode instead, then you can pass :option:`--log-file-mode=a`. Note that relative paths for the log-file location, whether passed on the CLI or declared in a config file, are always resolved relative to the current working directory. diff --git a/doc/en/how-to/skipping.rst b/doc/en/how-to/skipping.rst index 8cebab93c23..488f71b09f9 100644 --- a/doc/en/how-to/skipping.rst +++ b/doc/en/how-to/skipping.rst @@ -311,7 +311,7 @@ even executed, use the ``run`` parameter as ``False``: @pytest.mark.xfail(run=False) def test_function(): ... -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 investigated later. .. _`xfail strict tutorial`: diff --git a/doc/en/reference/exit-codes.rst b/doc/en/reference/exit-codes.rst index 3ea29015dee..49aaca19121 100644 --- a/doc/en/reference/exit-codes.rst +++ b/doc/en/reference/exit-codes.rst @@ -20,7 +20,7 @@ They are represented by the :class:`pytest.ExitCode` enum. The exit codes being .. note:: - 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 no tests are collected, consider using the `pytest-custom_exit_code `__ plugin. diff --git a/doc/en/reference/reference.rst b/doc/en/reference/reference.rst index a2f7a13de12..aa419d59ec5 100644 --- a/doc/en/reference/reference.rst +++ b/doc/en/reference/reference.rst @@ -3179,7 +3179,7 @@ See :ref:`logging` for a guide on using these flags. .. option:: --log-file=PATH - Path to a file where logging will be written to. + Path to a file logging will be written to. .. option:: --log-file-mode From 33761afc3a77a0d24a8af56c35e2fb80add8dd33 Mon Sep 17 00:00:00 2001 From: ron Date: Wed, 11 Feb 2026 08:40:17 -0500 Subject: [PATCH 3/3] doc: apply additional reviewer feedback from @webknjaz - changelog/12444.bugfix.rst: link Mapping class with :class: role - doc/en/explanation/ci.rst: link CI and BUILD_NUMBER with :envvar: role --- changelog/12444.bugfix.rst | 2 +- doc/en/explanation/ci.rst | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/changelog/12444.bugfix.rst b/changelog/12444.bugfix.rst index ef8a2167426..d4e804ac613 100644 --- a/changelog/12444.bugfix.rst +++ b/changelog/12444.bugfix.rst @@ -1 +1 @@ -Fixed :func:`pytest.approx` which now correctly takes into account Mapping keys order to compare them. +Fixed :func:`pytest.approx` which now correctly takes into account :class:`~collections.abc.Mapping` keys order to compare them. diff --git a/doc/en/explanation/ci.rst b/doc/en/explanation/ci.rst index 927c1075847..16f55be81c0 100644 --- a/doc/en/explanation/ci.rst +++ b/doc/en/explanation/ci.rst @@ -19,8 +19,8 @@ How CI is detected Pytest knows it is in a CI environment when either one of these environment variables is set to a non-empty value: -* `CI`: used by many CI systems. -* `BUILD_NUMBER`: used by Jenkins. +* :envvar:`CI`: used by many CI systems. +* :envvar:`BUILD_NUMBER`: used by Jenkins. Effects on CI -------------