Damien Nadé added the comment:
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 wou
Damien Nadé added the comment:
I've submitted a patch to mock_open, but if you think it's a bad approach, I'm
open to discussion.
--
___
Python tracker
<https://bugs.pyt
Change by Damien Nadé :
--
keywords: +patch
pull_requests: +14705
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14933
___
Python tracker
<https://bugs.python.org/issu
New submission from Damien Nadé :
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:
```
Change by Damien Nadé :
--
keywords: +patch
pull_requests: +13407
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue37008>
___
___
Py
New submission from Damien Nadé :
While we can iterate on a mock_open handle, it is not actually possible to
perform a next() on it.
My use case is the following: I have a file with a one-line header that I want
to skip. So, roughly, my code is like
with open(filename, 'r')
