[8.0.x] Upgrade blacken-doc to black's 2024 style (#11899) (#11900)

(cherry picked from commit 4546d54)

Co-authored-by: Pierre Sassoulas <[email protected]>

Author: nicoddemus

.pre-commit-config.yaml

@@ -8,7 +8,7 @@ repos:
     rev: 1.16.0
     hooks:
     -   id: blacken-docs
-        additional_dependencies: [black==23.7.0]
+        additional_dependencies: [black==24.1.1]
 -   repo: https://github.com/pre-commit/pre-commit-hooks
     rev: v4.5.0
     hooks:

doc/en/deprecations.rst

@@ -47,11 +47,9 @@ they are in fact part of the ``nose`` support.
         def teardown(self):
             self.resource.close()
 
-        def test_foo(self):
-            ...
+        def test_foo(self): ...
 
-        def test_bar(self):
-            ...
+        def test_bar(self): ...
 
 
 
@@ -66,11 +64,9 @@ Native pytest support uses ``setup_method`` and ``teardown_method`` (see :ref:`x
         def teardown_method(self):
             self.resource.close()
 
-        def test_foo(self):
-            ...
+        def test_foo(self): ...
 
-        def test_bar(self):
-            ...
+        def test_bar(self): ...
 
 
 This is easy to do in an entire code base by doing a simple find/replace.
@@ -85,17 +81,14 @@ Code using `@with_setup <with-setup-nose>`_ such as this:
     from nose.tools import with_setup
 
 
-    def setup_some_resource():
-        ...
+    def setup_some_resource(): ...
 
 
-    def teardown_some_resource():
-        ...
+    def teardown_some_resource(): ...
 
 
     @with_setup(setup_some_resource, teardown_some_resource)
-    def test_foo():
-        ...
+    def test_foo(): ...
 
 Will also need to be ported to a supported pytest style. One way to do it is using a fixture:
 
@@ -104,12 +97,10 @@ Will also need to be ported to a supported pytest style. One way to do it is usi
     import pytest
 
 
-    def setup_some_resource():
-        ...
+    def setup_some_resource(): ...
 
 
-    def teardown_some_resource():
-        ...
+    def teardown_some_resource(): ...
 
 
     @pytest.fixture
@@ -119,8 +110,7 @@ Will also need to be ported to a supported pytest style. One way to do it is usi
         teardown_some_resource()
 
 
-    def test_foo(some_resource):
-        ...
+    def test_foo(some_resource): ...
 
 
 .. _`with-setup-nose`: https://nose.readthedocs.io/en/latest/testing_tools.html?highlight=with_setup#nose.tools.with_setup
@@ -197,13 +187,11 @@ have been available since years and should be used instead.
 .. code-block:: python
 
     @pytest.mark.tryfirst
-    def pytest_runtest_call():
-        ...
+    def pytest_runtest_call(): ...
 
 
     # or
-    def pytest_runtest_call():
-        ...
+    def pytest_runtest_call(): ...
 
 
     pytest_runtest_call.tryfirst = True
@@ -213,8 +201,7 @@ should be changed to:
 .. code-block:: python
 
     @pytest.hookimpl(tryfirst=True)
-    def pytest_runtest_call():
-        ...
+    def pytest_runtest_call(): ...
 
 Changed ``hookimpl`` attributes:
 
@@ -317,17 +304,15 @@ Implement the :hook:`pytest_load_initial_conftests` hook instead.
 
 .. code-block:: python
 
-    def pytest_cmdline_preparse(config: Config, args: List[str]) -> None:
-        ...
+    def pytest_cmdline_preparse(config: Config, args: List[str]) -> None: ...
 
 
     # becomes:
 
 
     def pytest_load_initial_conftests(
         early_config: Config, parser: Parser, args: List[str]
-    ) -> None:
-        ...
+    ) -> None: ...
 
 .. _diamond-inheritance-deprecated:
 
@@ -391,8 +376,7 @@ Applying a mark to a fixture function never had any effect, but it is a common u
 
     @pytest.mark.usefixtures("clean_database")
     @pytest.fixture
-    def user() -> User:
-        ...
+    def user() -> User: ...
 
 Users expected in this case that the ``usefixtures`` mark would have its intended effect of using the ``clean_database`` fixture when ``user`` was invoked, when in fact it has no effect at all.
 
@@ -907,8 +891,7 @@ Applying marks to values of a ``pytest.mark.parametrize`` call is now deprecated
             (50, 500),
         ],
     )
-    def test_foo(a, b):
-        ...
+    def test_foo(a, b): ...
 
 This code applies the ``pytest.mark.xfail(reason="flaky")`` mark to the ``(6, 36)`` value of the above parametrization
 call.
@@ -931,8 +914,7 @@ To update the code, use ``pytest.param``:
             (50, 500),
         ],
     )
-    def test_foo(a, b):
-        ...
+    def test_foo(a, b): ...
 
 
 .. _pytest_funcarg__ prefix deprecated:
@@ -1083,15 +1065,13 @@ This is just a matter of renaming the fixture as the API is the same:
 
 .. code-block:: python
 
-    def test_foo(record_xml_property):
-        ...
+    def test_foo(record_xml_property): ...
 
 Change to:
 
 .. code-block:: python
 
-    def test_foo(record_property):
-        ...
+    def test_foo(record_property): ...
 
 
 .. _passing command-line string to pytest.main deprecated:
@@ -1253,8 +1233,7 @@ Example of usage:
 
 .. code-block:: python
 
-    class MySymbol:
-        ...
+    class MySymbol: ...
 
 
     def pytest_namespace():

doc/en/funcarg_compare.rst

@@ -99,8 +99,7 @@ sets.  pytest-2.3 introduces a decorator for use on the factory itself:
 .. code-block:: python
 
     @pytest.fixture(params=["mysql", "pg"])
-    def db(request):
-        ...  # use request.param
+    def db(request): ...  # use request.param
 
 Here the factory will be invoked twice (with the respective "mysql"
 and "pg" values set as ``request.param`` attributes) and all of
@@ -141,8 +140,7 @@ argument:
 .. code-block:: python
 
     @pytest.fixture()
-    def db(request):
-        ...
+    def db(request): ...
 
 The name under which the funcarg resource can be requested is ``db``.
 
@@ -151,8 +149,7 @@ aka:
 
 .. code-block:: python
 
-    def pytest_funcarg__db(request):
-        ...
+    def pytest_funcarg__db(request): ...
 
 
 But it is then not possible to define scoping and parametrization.

doc/en/historical-notes.rst

@@ -227,8 +227,7 @@ to use strings:
 
 
     @pytest.mark.skipif("sys.version_info >= (3,3)")
-    def test_function():
-        ...
+    def test_function(): ...
 
 During test function setup the skipif condition is evaluated by calling
 ``eval('sys.version_info >= (3,0)', namespace)``.  The namespace contains
@@ -262,8 +261,7 @@ configuration value which you might have added:
 .. code-block:: python
 
     @pytest.mark.skipif("not config.getvalue('db')")
-    def test_function():
-        ...
+    def test_function(): ...
 
 The equivalent with "boolean conditions" is:
 

doc/en/how-to/fixtures.rst

@@ -1721,8 +1721,7 @@ You can specify multiple fixtures like this:
 .. code-block:: python
 
     @pytest.mark.usefixtures("cleandir", "anotherfixture")
-    def test():
-        ...
+    def test(): ...
 
 and you may specify fixture usage at the test module level using :globalvar:`pytestmark`:
 
@@ -1750,8 +1749,7 @@ into an ini-file:
 
         @pytest.mark.usefixtures("my_other_fixture")
         @pytest.fixture
-        def my_fixture_that_sadly_wont_use_my_other_fixture():
-            ...
+        def my_fixture_that_sadly_wont_use_my_other_fixture(): ...
 
     This generates a deprecation warning, and will become an error in Pytest 8.
 

doc/en/how-to/skipping.rst

@@ -47,8 +47,7 @@ which may be passed an optional ``reason``:
 .. code-block:: python
 
     @pytest.mark.skip(reason="no way of currently testing this")
-    def test_the_unknown():
-        ...
+    def test_the_unknown(): ...
 
 
 Alternatively, it is also possible to skip imperatively during test execution or setup
@@ -93,8 +92,7 @@ when run on an interpreter earlier than Python3.10:
 
 
     @pytest.mark.skipif(sys.version_info < (3, 10), reason="requires python3.10 or higher")
-    def test_function():
-        ...
+    def test_function(): ...
 
 If the condition evaluates to ``True`` during collection, the test function will be skipped,
 with the specified reason appearing in the summary when using ``-rs``.
@@ -112,8 +110,7 @@ You can share ``skipif`` markers between modules.  Consider this test module:
 
 
     @minversion
-    def test_function():
-        ...
+    def test_function(): ...
 
 You can import the marker and reuse it in another test module:
 
@@ -124,8 +121,7 @@ You can import the marker and reuse it in another test module:
 
 
     @minversion
-    def test_anotherfunction():
-        ...
+    def test_anotherfunction(): ...
 
 For larger test suites it's usually a good idea to have one file
 where you define the markers which you then consistently apply
@@ -232,8 +228,7 @@ expect a test to fail:
 .. code-block:: python
 
     @pytest.mark.xfail
-    def test_function():
-        ...
+    def test_function(): ...
 
 This test will run but no traceback will be reported when it fails. Instead, terminal
 reporting will list it in the "expected to fail" (``XFAIL``) or "unexpectedly
@@ -275,8 +270,7 @@ that condition as the first parameter:
 .. code-block:: python
 
     @pytest.mark.xfail(sys.platform == "win32", reason="bug in a 3rd party library")
-    def test_function():
-        ...
+    def test_function(): ...
 
 Note that you have to pass a reason as well (see the parameter description at
 :ref:`pytest.mark.xfail ref`).
@@ -289,8 +283,7 @@ You can specify the motive of an expected failure with the ``reason`` parameter:
 .. code-block:: python
 
     @pytest.mark.xfail(reason="known parser issue")
-    def test_function():
-        ...
+    def test_function(): ...
 
 
 ``raises`` parameter
@@ -302,8 +295,7 @@ a single exception, or a tuple of exceptions, in the ``raises`` argument.
 .. code-block:: python
 
     @pytest.mark.xfail(raises=RuntimeError)
-    def test_function():
-        ...
+    def test_function(): ...
 
 Then the test will be reported as a regular failure if it fails with an
 exception not mentioned in ``raises``.
@@ -317,8 +309,7 @@ even executed, use the ``run`` parameter as ``False``:
 .. code-block:: python
 
     @pytest.mark.xfail(run=False)
-    def test_function():
-        ...
+    def test_function(): ...
 
 This is specially useful for xfailing tests that are crashing the interpreter and should be
 investigated later.
@@ -334,8 +325,7 @@ You can change this by setting the ``strict`` keyword-only parameter to ``True``
 .. code-block:: python
 
     @pytest.mark.xfail(strict=True)
-    def test_function():
-        ...
+    def test_function(): ...
 
 
 This will make ``XPASS`` ("unexpectedly passing") results from this test to fail the test suite.

doc/en/reference/reference.rst

@@ -164,8 +164,7 @@ Add warning filters to marked test items.
         .. code-block:: python
 
             @pytest.mark.filterwarnings("ignore:.*usage will be deprecated.*:DeprecationWarning")
-            def test_foo():
-                ...
+            def test_foo(): ...
 
 
 .. _`pytest.mark.parametrize ref`:
@@ -276,8 +275,7 @@ For example:
 .. code-block:: python
 
     @pytest.mark.timeout(10, "slow", method="thread")
-    def test_function():
-        ...
+    def test_function(): ...
 
 Will create and attach a :class:`Mark <pytest.Mark>` object to the collected
 :class:`Item <pytest.Item>`, which can then be accessed by fixtures or hooks with
@@ -294,8 +292,7 @@ Example for using multiple custom markers:
 
     @pytest.mark.timeout(10, "slow", method="thread")
     @pytest.mark.slow
-    def test_function():
-        ...
+    def test_function(): ...
 
 When :meth:`Node.iter_markers <_pytest.nodes.Node.iter_markers>` or :meth:`Node.iter_markers_with_node <_pytest.nodes.Node.iter_markers_with_node>` is used with multiple markers, the marker closest to the function will be iterated over first. The above example will result in ``@pytest.mark.slow`` followed by ``@pytest.mark.timeout(...)``.