Skip to content

Commit ab5f179

Browse files
[3.13] gh-101100: Fix Sphinx warnings in library/unittest.mock.rst (GH-124106) (#125190)
Co-authored-by: Hugo van Kemenade <[email protected]>
1 parent b6c17eb commit ab5f179

File tree

1 file changed

+30
-30
lines changed

1 file changed

+30
-30
lines changed

Doc/library/unittest.mock.rst

Lines changed: 30 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -68,7 +68,7 @@ available, and then make assertions about how they have been used:
6868
3
6969
>>> thing.method.assert_called_with(3, 4, 5, key='value')
7070

71-
:attr:`side_effect` allows you to perform side effects, including raising an
71+
:attr:`~Mock.side_effect` allows you to perform side effects, including raising an
7272
exception when a mock is called:
7373

7474
>>> from unittest.mock import Mock
@@ -737,16 +737,16 @@ the *new_callable* argument to :func:`patch`.
737737

738738
.. attribute:: __class__
739739

740-
Normally the :attr:`__class__` attribute of an object will return its type.
741-
For a mock object with a :attr:`spec`, ``__class__`` returns the spec class
740+
Normally the :attr:`!__class__` attribute of an object will return its type.
741+
For a mock object with a :attr:`!spec`, :attr:`!__class__` returns the spec class
742742
instead. This allows mock objects to pass :func:`isinstance` tests for the
743743
object they are replacing / masquerading as:
744744

745745
>>> mock = Mock(spec=3)
746746
>>> isinstance(mock, int)
747747
True
748748

749-
:attr:`__class__` is assignable to, this allows a mock to pass an
749+
:attr:`!__class__` is assignable to, this allows a mock to pass an
750750
:func:`isinstance` check without forcing you to use a spec:
751751

752752
>>> mock = Mock()
@@ -760,8 +760,8 @@ the *new_callable* argument to :func:`patch`.
760760
meaning of :class:`Mock`, with the exception of *return_value* and *side_effect*
761761
which have no meaning on a non-callable mock.
762762

763-
Mock objects that use a class or an instance as a :attr:`spec` or
764-
:attr:`spec_set` are able to pass :func:`isinstance` tests:
763+
Mock objects that use a class or an instance as a :attr:`!spec` or
764+
:attr:`!spec_set` are able to pass :func:`isinstance` tests:
765765

766766
>>> mock = Mock(spec=SomeClass)
767767
>>> isinstance(mock, SomeClass)
@@ -1175,7 +1175,7 @@ Calls made to the object will be recorded in the attributes
11751175
like :attr:`~Mock.call_args` and :attr:`~Mock.call_args_list`.
11761176

11771177
If :attr:`~Mock.side_effect` is set then it will be called after the call has
1178-
been recorded, so if :attr:`side_effect` raises an exception the call is still
1178+
been recorded, so if :attr:`!side_effect` raises an exception the call is still
11791179
recorded.
11801180

11811181
The simplest way to make a mock raise an exception when called is to make
@@ -1196,8 +1196,8 @@ The simplest way to make a mock raise an exception when called is to make
11961196
>>> m.mock_calls
11971197
[call(1, 2, 3), call('two', 'three', 'four')]
11981198

1199-
If :attr:`side_effect` is a function then whatever that function returns is what
1200-
calls to the mock return. The :attr:`side_effect` function is called with the
1199+
If :attr:`~Mock.side_effect` is a function then whatever that function returns is what
1200+
calls to the mock return. The :attr:`!side_effect` function is called with the
12011201
same arguments as the mock. This allows you to vary the return value of the
12021202
call dynamically, based on the input:
12031203

@@ -1214,7 +1214,7 @@ call dynamically, based on the input:
12141214

12151215
If you want the mock to still return the default return value (a new mock), or
12161216
any set return value, then there are two ways of doing this. Either return
1217-
:attr:`mock.return_value` from inside :attr:`side_effect`, or return :data:`DEFAULT`:
1217+
:attr:`~Mock.return_value` from inside :attr:`~Mock.side_effect`, or return :data:`DEFAULT`:
12181218

12191219
>>> m = MagicMock()
12201220
>>> def side_effect(*args, **kwargs):
@@ -1231,8 +1231,8 @@ any set return value, then there are two ways of doing this. Either return
12311231
>>> m()
12321232
3
12331233

1234-
To remove a :attr:`side_effect`, and return to the default behaviour, set the
1235-
:attr:`side_effect` to ``None``:
1234+
To remove a :attr:`~Mock.side_effect`, and return to the default behaviour, set the
1235+
:attr:`!side_effect` to ``None``:
12361236

12371237
>>> m = MagicMock(return_value=6)
12381238
>>> def side_effect(*args, **kwargs):
@@ -1245,7 +1245,7 @@ To remove a :attr:`side_effect`, and return to the default behaviour, set the
12451245
>>> m()
12461246
6
12471247

1248-
The :attr:`side_effect` can also be any iterable object. Repeated calls to the mock
1248+
The :attr:`~Mock.side_effect` can also be any iterable object. Repeated calls to the mock
12491249
will return values from the iterable (until the iterable is exhausted and
12501250
a :exc:`StopIteration` is raised):
12511251

@@ -1286,7 +1286,7 @@ objects of any type.
12861286

12871287
You may want a mock object to return ``False`` to a :func:`hasattr` call, or raise an
12881288
:exc:`AttributeError` when an attribute is fetched. You can do this by providing
1289-
an object as a :attr:`spec` for a mock, but that isn't always convenient.
1289+
an object as a :attr:`!spec` for a mock, but that isn't always convenient.
12901290

12911291
You "block" attributes by deleting them. Once deleted, accessing an attribute
12921292
will raise an :exc:`AttributeError`.
@@ -1455,7 +1455,7 @@ patch
14551455
If you are patching builtins in a module then you don't
14561456
need to pass ``create=True``, it will be added by default.
14571457

1458-
Patch can be used as a :class:`TestCase` class decorator. It works by
1458+
Patch can be used as a :class:`~unittest.TestCase` class decorator. It works by
14591459
decorating each test method in the class. This reduces the boilerplate
14601460
code when your test methods share a common patchings set. :func:`patch` finds
14611461
tests by looking for method names that start with ``patch.TEST_PREFIX``.
@@ -1493,7 +1493,7 @@ If the class is instantiated multiple times you could use
14931493
can set the *return_value* to be anything you want.
14941494

14951495
To configure return values on methods of *instances* on the patched class
1496-
you must do this on the :attr:`return_value`. For example::
1496+
you must do this on the :attr:`~Mock.return_value`. For example::
14971497

14981498
>>> class Class:
14991499
... def method(self):
@@ -1814,13 +1814,13 @@ context manager is a dictionary where created mocks are keyed by name::
18141814
patch methods: start and stop
18151815
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
18161816

1817-
All the patchers have :meth:`start` and :meth:`stop` methods. These make it simpler to do
1817+
All the patchers have :meth:`!start` and :meth:`!stop` methods. These make it simpler to do
18181818
patching in ``setUp`` methods or where you want to do multiple patches without
18191819
nesting decorators or with statements.
18201820

18211821
To use them call :func:`patch`, :func:`patch.object` or :func:`patch.dict` as
18221822
normal and keep a reference to the returned ``patcher`` object. You can then
1823-
call :meth:`start` to put the patch in place and :meth:`stop` to undo it.
1823+
call :meth:`!start` to put the patch in place and :meth:`!stop` to undo it.
18241824

18251825
If you are using :func:`patch` to create a mock for you then it will be returned by
18261826
the call to ``patcher.start``. ::
@@ -1837,7 +1837,7 @@ the call to ``patcher.start``. ::
18371837

18381838

18391839
A typical use case for this might be for doing multiple patches in the ``setUp``
1840-
method of a :class:`TestCase`::
1840+
method of a :class:`~unittest.TestCase`::
18411841

18421842
>>> class MyTest(unittest.TestCase):
18431843
... def setUp(self):
@@ -2510,7 +2510,7 @@ behaviour you can switch it off by setting the module level switch
25102510

25112511
Alternatively you can just use ``vars(my_mock)`` (instance members) and
25122512
``dir(type(my_mock))`` (type members) to bypass the filtering irrespective of
2513-
:const:`mock.FILTER_DIR`.
2513+
:const:`FILTER_DIR`.
25142514

25152515

25162516
mock_open
@@ -2525,7 +2525,7 @@ mock_open
25252525
default) then a :class:`MagicMock` will be created for you, with the API limited
25262526
to methods or attributes available on standard file handles.
25272527

2528-
*read_data* is a string for the :meth:`~io.IOBase.read`,
2528+
*read_data* is a string for the :meth:`~io.RawIOBase.read`,
25292529
:meth:`~io.IOBase.readline`, and :meth:`~io.IOBase.readlines` methods
25302530
of the file handle to return. Calls to those methods will take data from
25312531
*read_data* until it is depleted. The mock of these methods is pretty
@@ -2537,7 +2537,7 @@ mock_open
25372537

25382538
.. versionchanged:: 3.4
25392539
Added :meth:`~io.IOBase.readline` and :meth:`~io.IOBase.readlines` support.
2540-
The mock of :meth:`~io.IOBase.read` changed to consume *read_data* rather
2540+
The mock of :meth:`~io.RawIOBase.read` changed to consume *read_data* rather
25412541
than returning it on each call.
25422542

25432543
.. versionchanged:: 3.5
@@ -2589,7 +2589,7 @@ And for reading files::
25892589
Autospeccing
25902590
~~~~~~~~~~~~
25912591

2592-
Autospeccing is based on the existing :attr:`spec` feature of mock. It limits the
2592+
Autospeccing is based on the existing :attr:`!spec` feature of mock. It limits the
25932593
api of mocks to the api of an original object (the spec), but it is recursive
25942594
(implemented lazily) so that attributes of mocks only have the same api as
25952595
the attributes of the spec. In addition mocked functions / methods have the
@@ -2614,8 +2614,8 @@ unit tests. Testing everything in isolation is all fine and dandy, but if you
26142614
don't test how your units are "wired together" there is still lots of room
26152615
for bugs that tests might have caught.
26162616

2617-
:mod:`mock` already provides a feature to help with this, called speccing. If you
2618-
use a class or instance as the :attr:`spec` for a mock then you can only access
2617+
:mod:`unittest.mock` already provides a feature to help with this, called speccing. If you
2618+
use a class or instance as the :attr:`!spec` for a mock then you can only access
26192619
attributes on the mock that exist on the real class:
26202620

26212621
>>> from urllib import request
@@ -2653,7 +2653,7 @@ Here's an example of it in use::
26532653
>>> mock_request.Request
26542654
<MagicMock name='request.Request' spec='Request' id='...'>
26552655

2656-
You can see that :class:`request.Request` has a spec. :class:`request.Request` takes two
2656+
You can see that :class:`!request.Request` has a spec. :class:`!request.Request` takes two
26572657
arguments in the constructor (one of which is *self*). Here's what happens if
26582658
we try to call it incorrectly::
26592659

@@ -2669,8 +2669,8 @@ specced mocks)::
26692669
>>> req
26702670
<NonCallableMagicMock name='request.Request()' spec='Request' id='...'>
26712671

2672-
:class:`Request` objects are not callable, so the return value of instantiating our
2673-
mocked out :class:`request.Request` is a non-callable mock. With the spec in place
2672+
:class:`!Request` objects are not callable, so the return value of instantiating our
2673+
mocked out :class:`!request.Request` is a non-callable mock. With the spec in place
26742674
any typos in our asserts will raise the correct error::
26752675

26762676
>>> req.add_header('spam', 'eggs')
@@ -2822,8 +2822,8 @@ Sealing mocks
28222822
.. versionadded:: 3.7
28232823

28242824

2825-
Order of precedence of :attr:`side_effect`, :attr:`return_value` and *wraps*
2826-
----------------------------------------------------------------------------
2825+
Order of precedence of :attr:`!side_effect`, :attr:`!return_value` and *wraps*
2826+
------------------------------------------------------------------------------
28272827

28282828
The order of their precedence is:
28292829

0 commit comments

Comments
 (0)