classification
Title: mock.patch interactions with "from" imports
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: clarkbreyman, rbcollins, xtreak
Priority: normal Keywords:

Created on 2016-06-03 17:21 by clarkbreyman, last changed 2019-12-13 11:16 by xtreak.

Messages (2)
msg267114 - (view) Author: Clark Breyman (clarkbreyman) Date: 2016-06-03 17:21
Unclear if this is a code bug or a gotcha that should be documented:
Cross posted to https://github.com/testing-cabal/mock/issues/365

Since "from"-style imports in modules bind names on the first execution of the import, there is a subtle interaction with patching:

_If a name is imported when the source is patched, the imported name will refer to the patched version even after the source is restored_

Test case:
```python
# patchbug/__init__.py
#
```

```python
# patchbug/a.py
#
class A(object):
    def name(self):
        return "unpatched"
```

```python
# patchbug/b.py
#
from patchbug.a import A

def reference():
    return A().name()

# patchbug/tests.py
#
import mock

"""
patchbug.reference.UnpatchedClass is bound to the value of patchbug.source.UnpatchedClass
at the time of the first import of patchbug.reference. If patched at that time it is not repaired.
"""

def test_unpatched():
    import patchbug.a
    assert patchbug.a.A().name() == "unpatched"

"""
uncommenting the import causes reference.UnpatchedClass to be bound before the patch, fixing
test_reference and breaking test_unpatched
"""
def test_import_reference():
#    import patchbug.b
    pass

def test_patched():
    with mock.patch('patchbug.a.A') as P:
        import patchbug.a, patchbug.b
        P.return_value.name.return_value = "patched"
        assert patchbug.a.A().name() == "patched"
        assert patchbug.b.reference() == "patched"

def test_reference():
    import patchbug.b
    assert patchbug.b.reference() == "unpatched"
```
msg267162 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2016-06-03 21:04
So its a feature of mock that it can mock a module that doesn't exist. And the semantics of the import system are designed to be very cheap when a module is already imported - so when 'patchbug.a' is in sys.modules, import will correctly return it rather than going out to the import path to find if its the same thing.

We could possibly have an opt-in check on mock.patch to require that the thing being patched exists, but it would have to be opt-in as so many cases are dealing with optional or pretend instances. I'm not super keen on that though.

This is perhaps worth calling out in the docs to avoid confusion.
History
Date User Action Args
2019-12-13 11:16:14xtreaksetnosy: + xtreak
2016-06-03 21:04:32rbcollinssetnosy: + rbcollins
messages: + msg267162
2016-06-03 17:21:05clarkbreymancreate