Ezio Melotti added the comment:
IMHO a setattr-like API seems the obvious choice here, so that's what I would
expect. I haven't used mock, so I wasn't familiar with mock.patch, but after
skimming through the mock docs a bit I think I have to agree with Julian and
RDM.
In addition, I'm not sure we need TestCase.patch now that we have already have
mock.patch(.object) in the stdlib. If we still add it, it would probably make
more sense as a "vanilla" patch that doesn't depend on mock.
> a helper TestCase.patch should delegate to unittest.mock.patch
Does it mean it will return MagicMocks?
> patch.object would have worked as well, but it's longer to type
If mock.patch requires a FQN to work the call might even be longer:
patch('package.subpackage.module.function') vs
patch.object(module, 'function', newfunc)
(assuming "from package.subpackage import module", which is not uncommon if we
are testing that specific module)
> What about patch_object()?
patchobj()?
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue11664>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
