Author ezio.melotti
Recipients Julian, brett.cannon, chris.jerdonek, daniel.urban, eric.araujo, ezio.melotti, michael.foord, pablomouzo, r.david.murray
Date 2012-09-19.01:33:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1348018397.21.0.830884733914.issue11664@psf.upfronthosting.co.za>
In-reply-to
Content
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()?
History
Date User Action Args
2012-09-19 01:33:17ezio.melottisetrecipients: + ezio.melotti, brett.cannon, eric.araujo, r.david.murray, michael.foord, pablomouzo, daniel.urban, chris.jerdonek, Julian
2012-09-19 01:33:17ezio.melottisetmessageid: <1348018397.21.0.830884733914.issue11664@psf.upfronthosting.co.za>
2012-09-19 01:33:16ezio.melottilinkissue11664 messages
2012-09-19 01:33:16ezio.melotticreate