--- Log opened Wed Aug 08 00:00:11 2012
17:27 < tos9> voidspace: Hey.
17:27 < tos9> Where's the proper place to do some initialization for child mocks?
17:28 < tos9> (so, the equivalent of class Foo(mock.Mock): def __init__(self): super(Foo, self).__init__(); self.foo.return_value =  as an example)
17:28 < tos9> That seems to throw a RuntimeError for exceeding the recursion depth, for reasons unclear to me at the moment.
17:29 < tos9> (Other than the possibility that Mock is doing descriptor things and doing different things if it is accessing its own attributes, is that the case?)
17:40 < tos9> Oh. Never mind that last thing, I get what's happening, now to figure out how to make it not happe.
13:29 < voidspace> tos9: ping
13:29 < tos9> voidspace: 'ey.
13:29 < voidspace> tos9: did you resolve your problem with initiialisation of mock subclasses?
13:29 < voidspace> tos9: if you're accessing auto-created attributes in __init__ you need to override _get_child_mock too
13:30 < voidspace> that's probably obscure enough to warrant documenting
13:30 < tos9> voidspace: I found _get_child_mock in the docs.
13:30 < tos9> That's a bit hairy though :/
13:30 < tos9> (So I resorted to a factory function instead)
13:30 < voidspace> yeah, I can understand it being confusing
13:30 < voidspace> a factory function is just as good a solution to be honest
13:31 < voidspace> and you can still use it with patch with new_callable=factory_function
13:31 < tos9> Well, once I saw what was going on it wasn't confusing, but getting around it is annoying, I don't want to have to reimplement _get_child_mocks :). I'd have liked to have mock.Mock(child_class=mock.Mock)
13:32 < tos9> (But yeah, nothing wrong with the factory function certainly)
13:32 < voidspace> right
13:32 < voidspace> feel free to file a feature request
13:32 < tos9> Appreciate you getting back to me about it certainly :). Think I will, wouldn't be hard to implement if I get a minute this afternoon.