Terry J. Reedy <tjreedy@udel.edu> added the comment: My *guess* is that you created the branch for PR 7491 when your local master branch was months out of date. Or you branched off of the 3.7 branch. Whatever, your patch proposed to revert recent changes to master, touching about 1000 files. When you pushed the button on the github web page to compare and possibly make a PR, you should have seen a list of +- 1000 changes in the proposed PR, closed the window, deleted the branch on the fork and your repository, and started over with a new branch from freshly updated master. You are right that the review requests were automatic. However, I am not sure how the 6 month delay factors into what happened. Since Guido closed the PR rather than suggest fixing it further, I suggest that you start over as suggested above and look closely before pressing 'Create PR'. It appears that you already deleted the branch from the fork.

From my limited knowledge of how to use unitest.mock correctly, I agree that the example looks plausible.

---------- nosy: +terry.reedy _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue33722> _______________________________________

Karthikeyan Singaravelan <tir.karthi@gmail.com> added the comment: The example looks like a good addition to me since mocking builtins.open is not documented for this use case. Please start a new PR. ---------- nosy: +xtreak _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue33722> _______________________________________

Terry J. Reedy <tjreedy@udel.edu> added the comment: After looking at the context of the patch and thinking more about whether the patch is a good idea, I am reversing what I said before and think that this issue and the new patch (sorry) should be closed. 1. The new example duplicates the current example. The only difference is that one module name,'__main__', is replaced with another, 'builtins'. Mechanically, there is no difference, so the duplicate adds nothing. 2. The current example, contrary to the claim, "'__main__'.open is replaced", adds .open to __main__ and thereby masks builtins.open in, and only in, __main__. In use, '__main__' in all the current doc examples should be replaced by the name of the module where open is called. This would usually, but not necessarily, be the module being tested. This is explained in the section on where to patch. 3. Touching builtins is generally a bad idea unless one really understands and wants to affect *all* modules in the process, including the test code and unittest code. Beginners should *not* be encouraged to do this. If one replaces a builtin needed by test code or other untested mdoules before the replacement is undone, one disables the test code. The real problem, if any, with the mock examples, is that they usually do everything in one module (usually __main__) while real use involves code and execution in at least two modules. Users are left to work out which examples lines belong in text_xyz, which would be in xyz, and what essential code is missing. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue33722> _______________________________________

Change by Jay Crotts <crotts.jay@gmail.com>: ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue33722> _______________________________________