Let's say I have a function that opens 2 files and compare them. mock_open would not allow me to test this case, as it would return the same data for both files (through its read_data argument).

I want to be able to do this in a mocked-open context:
```
with open("file1") as file1:
    assert file1.read() == "data1"

with open("file2") as file2:
    assert file2.read() == "data2"
```

Can you suggest an API for doing this?

I've submitted a patch to mock_open, but if you think it's a bad approach, I'm open to discussion.

To summarize the change I'm proposing, I'd say that instead of having mock_open creating closures (functions inside a specific context), mock_open now creates objects that will hold the contexts. Each context would be filename-dedicated and would include specific 'read_data' and linked MagikMock object.

So the change is fully transparent compared to the currently-existing mock_open. It just brings a little extra something, in the way of an extra parameter to mock_open : 

mock_open(mock, read_data, data)

While the name 'data' obviously can (and should) be replaced before merge (I dont have a "good" name in mind ATM, feel free to suggest), I'm suggesting in my PR that it could be a {<file name>: <read data>} mapping.

e.g: If i call

mock_open(read_data="default read data", data={"/foo": "abc", "/asdf/bar": "xyz"})

Then, after mock.patching open, I can assert the following:

assert open("random file").read() == "default read data"
assert open("/foo").read() == "abc"
assert open("/bar").read() == "xyz"

And so far, that's all I'm proposing... But I'm really open to suggestion on that.

Using a side_effect is one way to achieve this currently if I understand the use case correctly. For every open side_effect will be called and hence it will return a new mock_open with read_data for the given filename used inside the context. This can handle nested calls since each will have it's own mock_open object. PR seems to do similar approach to refactor out to created predefined mock_open per filename and to return objects from a dictionary.


from unittest.mock import mock_open, patch

DEFAULT_MOCK_DATA = "default mock data"
data_dict = {"file1": "data1",
             "file2": "data2"}

def open_side_effect(name):
    return mock_open(read_data=data_dict.get(name, DEFAULT_MOCK_DATA))()

with patch(f"{__name__}.open", side_effect=open_side_effect):
    with open("file1") as file1:
        assert file1.read() == "data1"

        with open("file2") as file2:
            assert file2.read() == "data2"

            with open("file1") as file3:
                assert file3.read(1) == "d"

        assert file1.read() == ""

    with open("defaultfile") as file4:
        assert file4.read() == "default mock data"

Given that the enhancement can only land on 3.9 I guess it will be a good recipe on returning mock_open data for per file to be added to the unittest examples page.

I'm not sure I like the API feel after this change: two parameters that can't be used at the same time.

As Karthikeyan points out, this can be achieved using side_effect. Personally, I'd prefer a PR that adds a unit test showing that this approach works, and an example included in the docs as suggested above.

Also, be aware that there can be better options for mocking files. https://github.com/jmcgeheeiv/pyfakefs/ and https://docs.pytest.org/en/latest/tmpdir.html would be my recommendation.

Closing in favour of issue38157.