Merge lp:~jml/testtools/patch-310770 into lp:~testtools-committers/testtools/trunk

A few thoughts.

Firstly, I'd expect this to delete an attribute too, if the original
was unset; this doesn't, but the tests don't make it clear whether
that is oversight or intent.

Secondly, this is so useful, I really would rather not see it on TestCase.

How about

def patch(obj, attribute, value):
    """Set obj.attribute to value and return a cleanup to restore it."""

?

Then you can do
self.addCleanup(patch(sys, "stderr", StringIO())

I don't like that.

We have a really nice monkey-patching module in Twisted and it simply never gets used. The only thing that ends up being used is TestCase.patch.

The delattr thing rarely comes up in actual usage, but I agree that it's a good behaviour to have. Will fix that.

On Wed, Aug 4, 2010 at 10:32 PM, Jonathan Lange <email address hidden> wrote:
> I don't like that.
>
> We have a really nice monkey-patching module in Twisted and it simply never gets used. The only thing that ends up being used is TestCase.patch.

Why does that happen, do you think?

I'd really like others to be able to use this outside of TestCase,
e.g. for fixtures, so I'd _really_ like the core to be
not-on-TestCase, it has no justification to be there; having glue for
it on TestCase I'm ambivalent but not keen on, but ok with as long as
it really is a one-liner.

-Rob

It doesn't happen because the need for it is small, and it's almost always easier to write it yourself than add the import and re-use code.

Still, if you're OK with a TestCase.patch() convenience function I can dredge up the external library I added in previous revisions and make TestCase.patch() a one-liner.

> Still, if you're OK with a TestCase.patch() convenience function I can dredge up the external library I added in previous revisions and make TestCase.patch() a one-liner.

+1