Repository navigation
reset_mock resets MagicMock's magic methods in an unexpected way #123934
Description
Bug report
Bug description:
The reset_mock(return_value=True) method behaves in a wrong/inconsistent way.
When used with MagicMock, the method reset_mock(return_value=True) does not reset the return values of the magic methods. Only if you call for example __str__ and then call the reset_mock function, the return value will be reset, but not to the default value.
from unittest import mock
mm = mock.MagicMock()
print(type(mm.__str__()))
mm.reset_mock(return_value=True)
print(type(mm.__str__()))
print(type(mm.__hash__()))
mm.reset_mock(return_value=True)
print(type(mm.__hash__()))Output
<class 'str'>
<class 'unittest.mock.MagicMock'>
<class 'int'>
<class 'unittest.mock.MagicMock'>Since Python 3.9 PR reset_mock now also resets child mocks. This explains the behaviour. Calling the __str__ method creates a child MagicMock with a set return value. Since this child mock now exists, its return value is reset when reset_mock(return_value=True) is called.
Although this can be logically explained, it's counter-intuitive and annoying as I'm never sure which values are being reset.
I would expect the same behaviour as Mock. The return value of __str__ and other magic methods should not be effected.
from unittest import mock
m = mock.Mock()
print(type(m.__str__()))
m.reset_mock(return_value=True)
print(type(m.__str__()))
print(type(m.__hash__()))
m.reset_mock(return_value=True)
print(type(m.__hash__()))Output
<class 'str'>
<class 'str'>
<class 'int'>
<class 'int'>CPython versions tested on:
3.10
Operating systems tested on:
Linux
Activity
[-]reset_mock resets MagicMock's magic methods in an unexpected way[/-][+]`reset_mock` resets `MagicMock`'s magic methods in an unexpected way[/+]sobolevn commentedon Sep 11, 2024
Thank you for the report. I will take a look soon :)
pythongh-123934: Fix `MagicMock` not to reset magic method return values
sobolevn commentedon Sep 13, 2024
Yes, this is correct.
Mockdoes not mock magic methods at all, so they are unaffected at any case. Compare:But, I agree that retuning
<class 'unittest.mock.MagicMock'>from__str__is not correct.So, my proposed solution is to ignore cases when:
MagicMockinstancereturn_valueisTruegh-123934: Fix `MagicMock` not to reset magic method return values (#…
pythongh-123934: Fix `MagicMock` not to reset magic method return val…
pythongh-123934: Fix `MagicMock` not to reset magic method return val…
[3.12] gh-123934: Fix `MagicMock` not to reset magic method return va…
pythongh-123934: Fix `MagicMock` not to reset magic method return val…
[3.13] gh-123934: Fix `MagicMock` not to reset magic method return va…
hroncok commentedon Nov 18, 2024
I see that this test in mu-editor fails with infinite RecursionError:
https://github.com/mu-editor/mu/blob/7641d7ada71a986f895ebd8a26d2ee2f52c3f1fe/tests/modes/test_python3.py#L486-L490
I believe this is because it is calling reset_mock on a mock of super and after this PR reset_mock calls super.
I think that mocking super is probably dangerous (and always has been), but I thought I should mention this here.
sobolevn commentedon Nov 18, 2024
Hm, I think that we can not use
super()for this feature technically. But, I think that mockingsuper()is dangerous indeed.What do others think? Should we fix this?
Tests: Avoid calling reset_mock() on a mock of super() to avoid Recur…
hroncok commentedon Nov 18, 2024
FWIW this particular use case was simple enough to fix: mu-editor/mu#2528
Tests: Avoid calling reset_mock() on a mock of super() to avoid Recur…
hugovk commentedon Feb 5, 2025
Triage: PR merged and backported.
The output on 3.12 and 3.14 is now as expected:
Please re-open if there's more to do.