Export to GitHub

pymox - issue #9

Deprecation warnings when __new__ is stubbed using python 2.6


Posted on May 26, 2009 by Grumpy Ox

What steps will reproduce the problem? 1. Stub out new on a class without an explicit new definition when using Python 2.6 2. Unset stubs 3. Try to instantiate the class again

What is the expected output? What do you see instead?

Everything works as expected except that there is a deprecation warning: DeprecationWarning: object.new() takes no parameters

What version of the product are you using? On what operating system? Mox 0.50, OS X, but most importantly Python 2.6.2 (or any other 2.6.x)

Please provide any additional information below. This seems to be another edge case of python weirdness that isn't explicitly covered by mox. Classes that don't explicitly define new use a special, built-in version defined by python. It doesn't seem to be possible to recover this version, or at least properly rebind it, when stubs are unset (or something like that, I don't quite understand the magic). The result seems to be that new is called for object with all args intact. As of 2.6 object.new only accepts the cls parameter and barfs a DeprecationWarning if it gets extra args. While it doesn't actually break anything the warnings are pretty annoying and presumably it will become a breaking problem when extra args are truly deprecated.

I've attached a patch that fixes the problem as well as a test script that demonstrates the issue using both mox and just the generic issue in python. All the patch does is watch for attempts to stub out new when the existing implementation is a built-in method. If that's the case it stubs out new it will unstub with a lambda that calls new on the parent class without any extra args.

Attachments

Comment #1

Posted on May 27, 2009 by Massive Panda

I'm not sure that you should be stubbing out new, but instead, stubbing out the whole object.

Do you know of a case where stubbing out new is better, or the only way to stub out a class?

I'll use the example recently discussed on the mailing list, both of which work for new style classes with no-arg __init__s. I'm not sure about other cases, since I haven't tested them myself.

Good

m.StubOutWithMock(xmpp.protocol, "JID", use_mock_anything=True)

vs.

Why do you need to do this?

m.StubOutWithMock(xmpp.protocol.JID, "new", use_mock_anything=True)

... other setup code

xmmpp.protocol.JID().AndReturn(my_mock_jid)

Comment #2

Posted on May 28, 2009 by Grumpy Ox

Ah!, you're right! Didn't even occur to me to mock it out that way. Maybe sit on the patch until it really becomes an issue? I'm just wondering if there are any other builtin methods that would require a similar technique.

Thanks!

Comment #3

Posted on May 28, 2009 by Massive Panda

Sounds good. :)

Status: WontFix

Labels:
Type-Defect Priority-Medium