Skip to content

Commit 7187d4f

Browse files
[3.12] gh-101100: Fix Sphinx warnings in library/unittest.mock.rst (GH-124106) (#125191)
Co-authored-by: Hugo van Kemenade <[email protected]>
1 parent 0dbad1d commit 7187d4f

File tree

1 file changed

+30
-30
lines changed

1 file changed

+30
-30
lines changed

Doc/library/unittest.mock.rst

+30-30
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
@@ -756,16 +756,16 @@ the *new_callable* argument to :func:`patch`.
756756

757757
.. attribute:: __class__
758758

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

764764
>>> mock = Mock(spec=3)
765765
>>> isinstance(mock, int)
766766
True
767767

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

771771
>>> mock = Mock()
@@ -779,8 +779,8 @@ the *new_callable* argument to :func:`patch`.
779779
meaning of :class:`Mock`, with the exception of *return_value* and *side_effect*
780780
which have no meaning on a non-callable mock.
781781

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

785785
>>> mock = Mock(spec=SomeClass)
786786
>>> isinstance(mock, SomeClass)
@@ -1149,7 +1149,7 @@ Calls made to the object will be recorded in the attributes
11491149
like :attr:`~Mock.call_args` and :attr:`~Mock.call_args_list`.
11501150

11511151
If :attr:`~Mock.side_effect` is set then it will be called after the call has
1152-
been recorded, so if :attr:`side_effect` raises an exception the call is still
1152+
been recorded, so if :attr:`!side_effect` raises an exception the call is still
11531153
recorded.
11541154

11551155
The simplest way to make a mock raise an exception when called is to make
@@ -1170,8 +1170,8 @@ The simplest way to make a mock raise an exception when called is to make
11701170
>>> m.mock_calls
11711171
[call(1, 2, 3), call('two', 'three', 'four')]
11721172

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

@@ -1188,7 +1188,7 @@ call dynamically, based on the input:
11881188

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

11931193
>>> m = MagicMock()
11941194
>>> def side_effect(*args, **kwargs):
@@ -1205,8 +1205,8 @@ any set return value, then there are two ways of doing this. Either return
12051205
>>> m()
12061206
3
12071207

1208-
To remove a :attr:`side_effect`, and return to the default behaviour, set the
1209-
:attr:`side_effect` to ``None``:
1208+
To remove a :attr:`~Mock.side_effect`, and return to the default behaviour, set the
1209+
:attr:`!side_effect` to ``None``:
12101210

12111211
>>> m = MagicMock(return_value=6)
12121212
>>> def side_effect(*args, **kwargs):
@@ -1219,7 +1219,7 @@ To remove a :attr:`side_effect`, and return to the default behaviour, set the
12191219
>>> m()
12201220
6
12211221

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

@@ -1260,7 +1260,7 @@ objects of any type.
12601260

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

12651265
You "block" attributes by deleting them. Once deleted, accessing an attribute
12661266
will raise an :exc:`AttributeError`.
@@ -1429,7 +1429,7 @@ patch
14291429
If you are patching builtins in a module then you don't
14301430
need to pass ``create=True``, it will be added by default.
14311431

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

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

14721472
>>> class Class:
14731473
... def method(self):
@@ -1788,13 +1788,13 @@ context manager is a dictionary where created mocks are keyed by name::
17881788
patch methods: start and stop
17891789
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
17901790

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

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

17991799
If you are using :func:`patch` to create a mock for you then it will be returned by
18001800
the call to ``patcher.start``. ::
@@ -1811,7 +1811,7 @@ the call to ``patcher.start``. ::
18111811

18121812

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

18161816
>>> class MyTest(unittest.TestCase):
18171817
... def setUp(self):
@@ -2484,7 +2484,7 @@ behaviour you can switch it off by setting the module level switch
24842484

24852485
Alternatively you can just use ``vars(my_mock)`` (instance members) and
24862486
``dir(type(my_mock))`` (type members) to bypass the filtering irrespective of
2487-
:const:`mock.FILTER_DIR`.
2487+
:const:`FILTER_DIR`.
24882488

24892489

24902490
mock_open
@@ -2499,7 +2499,7 @@ mock_open
24992499
default) then a :class:`MagicMock` will be created for you, with the API limited
25002500
to methods or attributes available on standard file handles.
25012501

2502-
*read_data* is a string for the :meth:`~io.IOBase.read`,
2502+
*read_data* is a string for the :meth:`~io.RawIOBase.read`,
25032503
:meth:`~io.IOBase.readline`, and :meth:`~io.IOBase.readlines` methods
25042504
of the file handle to return. Calls to those methods will take data from
25052505
*read_data* until it is depleted. The mock of these methods is pretty
@@ -2511,7 +2511,7 @@ mock_open
25112511

25122512
.. versionchanged:: 3.4
25132513
Added :meth:`~io.IOBase.readline` and :meth:`~io.IOBase.readlines` support.
2514-
The mock of :meth:`~io.IOBase.read` changed to consume *read_data* rather
2514+
The mock of :meth:`~io.RawIOBase.read` changed to consume *read_data* rather
25152515
than returning it on each call.
25162516

25172517
.. versionchanged:: 3.5
@@ -2563,7 +2563,7 @@ And for reading files::
25632563
Autospeccing
25642564
~~~~~~~~~~~~
25652565

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

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

25952595
>>> from urllib import request
@@ -2627,7 +2627,7 @@ Here's an example of it in use::
26272627
>>> mock_request.Request
26282628
<MagicMock name='request.Request' spec='Request' id='...'>
26292629

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

@@ -2643,8 +2643,8 @@ specced mocks)::
26432643
>>> req
26442644
<NonCallableMagicMock name='request.Request()' spec='Request' id='...'>
26452645

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

26502650
>>> req.add_header('spam', 'eggs')
@@ -2796,8 +2796,8 @@ Sealing mocks
27962796
.. versionadded:: 3.7
27972797

27982798

2799-
Order of precedence of :attr:`side_effect`, :attr:`return_value` and *wraps*
2800-
----------------------------------------------------------------------------
2799+
Order of precedence of :attr:`!side_effect`, :attr:`!return_value` and *wraps*
2800+
------------------------------------------------------------------------------
28012801

28022802
The order of their precedence is:
28032803

0 commit comments

Comments
 (0)