[TIP] failing tests after upgrading Mock 0.7 to 0.8

[Michael Foord]

On 20 Nov 2012, at 22:36, Julian Berman <julian at grayvines.com> wrote:

> While I certainly agree with Martin (that in Python I would not expect this to
> appear in a changelog, and subclasses should always be upcalling) a quick
> bisect shows that the change that did this was revision 772:
> 
> http://code.google.com/p/mock/source/diff?spec=svna0f74bb6496ae81a7a4ebcd23d1f7475269c6d63&name=a0f74bb6496a&r=a0f74bb6496ae81a7a4ebcd23d1f7475269c6d63&format=side&path=/mock.py&old_path=/mock.py&old=ff757c620ad225011d3d91e2da3a7bcc7b4c9422
> 


A nice piece of detective work. The reason for this change was that a significant proportion of the initialisation time of Mock / MagicMock was being spent inside __setattr__. Mock instantiation time was improved *a great deal* by short-cutting all of that and setting the attributes directly in the instance __dict__. Plus I always considered that check at the start of __setattr__ a hack and it was nice to get rid of it (reducing the post-initialisation cost of attribute setting a little bit as a nice side effect).

> where mocks stopped relying on having __setattr__ being ignored during
> initialization. I am guessing that at one point or another Michael Foord will
> chime in anyhow but it seems like the reason for the change is just because
> that isn't really documented behavior that was meant to be relied upon, as
> above, and since things are a bit simpler this way, sooner or later it was just
> made, and your thing broke.

I had no idea that this change would be visible to users subclassing but not initialising. I would consider code that does this buggy, and as I pointed out in my other email, *demonstrably buggy* in most cases even with the previous version of mock.

All the best,

Michael Foord


> 
> So yeah, I'd personally recommend that you just tell everyone to call super,
> since this is usually the thing that's expected to be happening when
> subclassing. Here especially, the things __init__ is setting up are enabling
> mock to distinguish things like non-mock attributes etc. which is definitely
> needed.
> 
> Cheers,
> Julian
> 
> 
> On Wed, Nov 21, 2012 at 09:08:06AM +1100, Martin Pool wrote:
>> On 21 November 2012 09:03, Martin Pool <mbp at sourcefrog.net> wrote:
>> 
>>    On 21 November 2012 08:47, Michael <mock at webhippo.net> wrote:
>> 
>>        I would like to respectfully answer this:
>>         
>> 
>>    It doesn't look like you succeeded in answering respectfully.
>>     
>> 
>>         
>> 
>>        This is a super un-useful answer.
>> 
>>        1. Yes it worked in 0.7.2
>>        2. No the docs did not mention the __init__/super was call was
>>        required. For all we knew it was not required.
>>        3. The docs also do not mention like all kinds of things, like that one
>>        should step on one foot while using mock ... that does not mean we
>>        should do them.
>> 
>> 
>> That's true; nor does it mention you must have Python installed, or your
>> computer must be switched on.  I don't think it would be useful for every
>> Python library's documentation to repeat the basics of how to use Python.
>> 
>> I don't think super constructor calls are an especially well designed aspect of
>> Python, because the default behavior is generally not what you want (not to
>> mention multiple inheritance.)  But, it is what it is, and code that doesn't
>> call upwards is generally wrong already.
>> 
>> I expect if you sent a patch to Mock that does mention this they'd probably
>> take it.
>> 
>> --
>> Martin
>> 
> 
>> _______________________________________________
>> testing-in-python mailing list
>> testing-in-python at lists.idyll.org
>> http://lists.idyll.org/listinfo/testing-in-python
> 
> 
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
> 


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html