Both unittest.mock and the backported release for earlier pythons don't appear to support mocking of dictionary objects.

Specifically I'm expecting that any of the methods used to test for membership, or get items from a mock object wrapping a dictionary should succeed. However it appears that MagicMock doesn't appear to support this.

Attached file shows an attempt to use different methods with a wrapped dictionary object where only the '.get()' method appears to work as expected.

Looking at the source, it's not clear that wraps is supported for __ methods, despite what the documentation implies.  That is, MagicProxy doesn't seem to look at the wraps information.  I suspect it is doable, but it may be an enhancement request rather than a bug fix, I'm not sure.

I think this is a valid mock bug; it likely needs some thoughtful exhaustive testing, and obviously support added for it.

The assertions in the attached test still fail on master (3.8a3), so this still applies. 

Michael, are you able to look at this, the code hasn't changed since the original PEP417 implementation, which doesn't specify if this behaviour should be supported.

The documentation does not specify that this is supported also, so i suspect this is an enhancement request.

        elif result is None:
            wraps = None
            if self._mock_wraps is not None:
                # XXXX should we get the attribute without triggering code
                # execution?
                wraps = getattr(self._mock_wraps, name)

            result = self._get_child_mock(
                parent=self, name=name, wraps=wraps, _new_name=name,
                _new_parent=self
            )

This seems to a reasonable change to me since dict.get returns the value then making a contains check dict.__contains__ should return True instead of the fixed return value of False. Below is a patch where the mock_wraps attribute is set with the relevant method that would make sure in the report dict.get would used.


diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py
index 298b41e0d7..077d22d08e 100644
--- a/Lib/unittest/mock.py
+++ b/Lib/unittest/mock.py
@@ -1935,6 +1935,12 @@ _side_effect_methods = {


 def _set_return_value(mock, method, name):
+    # If _mock_wraps is present then attach it so that it's return
+    # value is used when called.
+    if mock._mock_wraps is not None:
+        method._mock_wraps = getattr(mock._mock_wraps, name)
+        return
+
     fixed = _return_values.get(name, DEFAULT)
     if fixed is not DEFAULT:
         method.return_value = fixed

Michael, any thoughts on this? This more feels like an enhancement to me and I have marked it as 3.9 since I am not sure someone might be depending on the behavior where they have used wraps but still expect default values for magicmethods as they do now.

As discussed with Karthik, I think this is a nice feature enhancement for the wraps functionality and worth fixing. It has the great advantage that the fix is nice and isolated and simple.

The previous behaviour was unspecified and clearly due to missing functionality, so the advantages of fixing it outweigh any potential compatibility issues. But I'd see it as a feature enhancement for 3.9.

New changeset 72b1004657e60c900e4cd031b2635b587f4b280e by Chris Withers (Karthikeyan Singaravelan) in branch 'master':
bpo-25597: Ensure wraps' return value is used for magic methods in MagicMock (#16029)
https://github.com/python/cpython/commit/72b1004657e60c900e4cd031b2635b587f4b280e

New changeset 521c8d6806adf0305c158d280ec00cca48e8ab22 by Karthikeyan Singaravelan in branch 'master':
bpo-39966: Revert "bpo-25597: Ensure wraps' return value is used for magic methods in MagicMock" (GH-19734)
https://github.com/python/cpython/commit/521c8d6806adf0305c158d280ec00cca48e8ab22

The change has been reverted as per issue39966. I am reopening this for further discussion.

I went through dunder methods to check if any other operators or builtins work on objects without respective dunder methods:

 - del x works even though there is no object.__del__

 - operator.length_hint() => 0 when there is no object.__length_hint__

So in addition to __bool__, these dunder methods would have to be special cased.