[TIP] failing tests after upgrading Mock 0.7 to 0.8
ned at nedbatchelder.com
Tue Nov 20 14:46:21 PST 2012
On 11/20/2012 5:08 PM, Martin Pool wrote:
> On 21 November 2012 09:03, Martin Pool <mbp at sourcefrog.net
> <mailto:mbp at sourcefrog.net>> wrote:
> On 21 November 2012 08:47, Michael <mock at webhippo.net
> <mailto: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 agree: this is common Python practice. If you are subclassing, you
should initialize your parent. Mock 0.7.2 must not have had any
attributes initialized in its constructor. Now in 0.8 it does. If you
subclass Mock, you must call Mock.__init__ to properly initialize the
base class. It is also easy to overlook this step, and to have bugs
introduced later as a result.
> I expect if you sent a patch to Mock that does mention this they'd
> probably take it.
If I were the author of Mock and got this doc patch, I would add it as,
"And of course, as with all subclassing in Python, don't forget to call
Mock's __init__ method."
PS: I understand the idea that by default the parent should get
initialized, but explicit is better than implicit, and invoking the
parent's __init__ explicitly gives you some control over where in the
child's __init__ it is invoked, what arguments it gets, and so on.
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the testing-in-python