Upgrade blacken-doc to black's 2024 style (#11899)

This commit is contained in:
Pierre Sassoulas 2024-01-31 13:53:21 +01:00 committed by GitHub
parent de161f8791
commit 4546d5445a
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
7 changed files with 42 additions and 83 deletions

View File

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

View File

@ -33,13 +33,11 @@ have been available since years and should be used instead.
.. code-block:: python .. code-block:: python
@pytest.mark.tryfirst @pytest.mark.tryfirst
def pytest_runtest_call(): def pytest_runtest_call(): ...
...
# or # or
def pytest_runtest_call(): def pytest_runtest_call(): ...
...
pytest_runtest_call.tryfirst = True pytest_runtest_call.tryfirst = True
@ -49,8 +47,7 @@ should be changed to:
.. code-block:: python .. code-block:: python
@pytest.hookimpl(tryfirst=True) @pytest.hookimpl(tryfirst=True)
def pytest_runtest_call(): def pytest_runtest_call(): ...
...
Changed ``hookimpl`` attributes: Changed ``hookimpl`` attributes:
@ -146,8 +143,7 @@ Applying a mark to a fixture function never had any effect, but it is a common u
@pytest.mark.usefixtures("clean_database") @pytest.mark.usefixtures("clean_database")
@pytest.fixture @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. 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.
@ -308,11 +304,9 @@ they are in fact part of the ``nose`` support.
def teardown(self): def teardown(self):
self.resource.close() self.resource.close()
def test_foo(self): def test_foo(self): ...
...
def test_bar(self): def test_bar(self): ...
...
@ -327,11 +321,9 @@ Native pytest support uses ``setup_method`` and ``teardown_method`` (see :ref:`x
def teardown_method(self): def teardown_method(self):
self.resource.close() 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. This is easy to do in an entire code base by doing a simple find/replace.
@ -346,17 +338,14 @@ Code using `@with_setup <with-setup-nose>`_ such as this:
from nose.tools import with_setup 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) @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: Will also need to be ported to a supported pytest style. One way to do it is using a fixture:
@ -365,12 +354,10 @@ Will also need to be ported to a supported pytest style. One way to do it is usi
import pytest import pytest
def setup_some_resource(): def setup_some_resource(): ...
...
def teardown_some_resource(): def teardown_some_resource(): ...
...
@pytest.fixture @pytest.fixture
@ -380,8 +367,7 @@ Will also need to be ported to a supported pytest style. One way to do it is usi
teardown_some_resource() 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 .. _`with-setup-nose`: https://nose.readthedocs.io/en/latest/testing_tools.html?highlight=with_setup#nose.tools.with_setup
@ -500,8 +486,7 @@ Implement the :hook:`pytest_load_initial_conftests` hook instead.
.. code-block:: python .. code-block:: python
def pytest_cmdline_preparse(config: Config, args: List[str]) -> None: def pytest_cmdline_preparse(config: Config, args: List[str]) -> None: ...
...
# becomes: # becomes:
@ -509,8 +494,7 @@ Implement the :hook:`pytest_load_initial_conftests` hook instead.
def pytest_load_initial_conftests( def pytest_load_initial_conftests(
early_config: Config, parser: Parser, args: List[str] early_config: Config, parser: Parser, args: List[str]
) -> None: ) -> None: ...
...
Collection changes in pytest 8 Collection changes in pytest 8
@ -925,8 +909,7 @@ Applying marks to values of a ``pytest.mark.parametrize`` call is now deprecated
(50, 500), (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 This code applies the ``pytest.mark.xfail(reason="flaky")`` mark to the ``(6, 36)`` value of the above parametrization
call. call.
@ -949,8 +932,7 @@ To update the code, use ``pytest.param``:
(50, 500), (50, 500),
], ],
) )
def test_foo(a, b): def test_foo(a, b): ...
...
.. _pytest_funcarg__ prefix deprecated: .. _pytest_funcarg__ prefix deprecated:
@ -1101,15 +1083,13 @@ This is just a matter of renaming the fixture as the API is the same:
.. code-block:: python .. code-block:: python
def test_foo(record_xml_property): def test_foo(record_xml_property): ...
...
Change to: Change to:
.. code-block:: python .. code-block:: python
def test_foo(record_property): def test_foo(record_property): ...
...
.. _passing command-line string to pytest.main deprecated: .. _passing command-line string to pytest.main deprecated:
@ -1271,8 +1251,7 @@ Example of usage:
.. code-block:: python .. code-block:: python
class MySymbol: class MySymbol: ...
...
def pytest_namespace(): def pytest_namespace():

View File

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

View File

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

View File

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

View File

@ -47,8 +47,7 @@ which may be passed an optional ``reason``:
.. code-block:: python .. code-block:: python
@pytest.mark.skip(reason="no way of currently testing this") @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 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") @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, 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``. 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 @minversion
def test_function(): def test_function(): ...
...
You can import the marker and reuse it in another test module: 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 @minversion
def test_anotherfunction(): def test_anotherfunction(): ...
...
For larger test suites it's usually a good idea to have one file For larger test suites it's usually a good idea to have one file
where you define the markers which you then consistently apply where you define the markers which you then consistently apply
@ -232,8 +228,7 @@ expect a test to fail:
.. code-block:: python .. code-block:: python
@pytest.mark.xfail @pytest.mark.xfail
def test_function(): def test_function(): ...
...
This test will run but no traceback will be reported when it fails. Instead, terminal 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 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 .. code-block:: python
@pytest.mark.xfail(sys.platform == "win32", reason="bug in a 3rd party library") @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 Note that you have to pass a reason as well (see the parameter description at
:ref:`pytest.mark.xfail ref`). :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 .. code-block:: python
@pytest.mark.xfail(reason="known parser issue") @pytest.mark.xfail(reason="known parser issue")
def test_function(): def test_function(): ...
...
``raises`` parameter ``raises`` parameter
@ -302,8 +295,7 @@ a single exception, or a tuple of exceptions, in the ``raises`` argument.
.. code-block:: python .. code-block:: python
@pytest.mark.xfail(raises=RuntimeError) @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 Then the test will be reported as a regular failure if it fails with an
exception not mentioned in ``raises``. exception not mentioned in ``raises``.
@ -317,8 +309,7 @@ even executed, use the ``run`` parameter as ``False``:
.. code-block:: python .. code-block:: python
@pytest.mark.xfail(run=False) @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 This is specially useful for xfailing tests that are crashing the interpreter and should be
investigated later. investigated later.
@ -334,8 +325,7 @@ You can change this by setting the ``strict`` keyword-only parameter to ``True``
.. code-block:: python .. code-block:: python
@pytest.mark.xfail(strict=True) @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. This will make ``XPASS`` ("unexpectedly passing") results from this test to fail the test suite.

View File

@ -164,8 +164,7 @@ Add warning filters to marked test items.
.. code-block:: python .. code-block:: python
@pytest.mark.filterwarnings("ignore:.*usage will be deprecated.*:DeprecationWarning") @pytest.mark.filterwarnings("ignore:.*usage will be deprecated.*:DeprecationWarning")
def test_foo(): def test_foo(): ...
...
.. _`pytest.mark.parametrize ref`: .. _`pytest.mark.parametrize ref`:
@ -276,8 +275,7 @@ For example:
.. code-block:: python .. code-block:: python
@pytest.mark.timeout(10, "slow", method="thread") @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 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 :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.timeout(10, "slow", method="thread")
@pytest.mark.slow @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(...)``. 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(...)``.