This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Mock does not create deepcopy of mutable args
Type: Stage: resolved
Components: Tests Versions: Python 3.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: michael.foord, skraynev
Priority: normal Keywords:

Created on 2018-01-23 07:24 by skraynev, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
test.py skraynev, 2018-01-23 07:24 Test Example
Messages (2)
msg310476 - (view) Author: Sergey (skraynev) Date: 2018-01-23 07:24
MagicMock allows to check parameters of calls by using "assert_has_calls". However it fails if argument has a mutable type and was changed in-place before the second call.

The example is provided in attached file.

In "func1" value in "data" changes for each iteration and as result:
call_args_list contains two same calls.
In "func2" variable "data" generates by function "get_dict" and in this case call_args_list contains correct values.

Obviously it happens because class _Call (https://github.com/python/cpython/blob/3.5/Lib/unittest/mock.py#L1929) does not create a deepcopy of call args/kwargs.

Will it be correct to add deep_copy logic in mock.py ? or may be it's wrong to use logic like in "func1"? 
I see only one disadvantage of using deepcopy: it will become slower.
msg310488 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2018-01-23 09:31
There are several disadvantages to doing deepcopy:

* identity checks now fail
* deep copying is slow
* deep copying doesn't work on arbitrary objects

So deep copying by default isn't a good idea. This particular case is mentioned in the docs, with an example of a deep-copying mock if you need one.
History
Date User Action Args
2022-04-11 14:58:56adminsetgithub: 76813
2018-01-23 09:31:13michael.foordsetstatus: open -> closed
resolution: not a bug
messages: + msg310488

stage: resolved
2018-01-23 07:24:45skraynevcreate