This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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 <>
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()?

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: <>
2012-09-19 01:33:16ezio.melottilinkissue11664 messages
2012-09-19 01:33:16ezio.melotticreate