Deprecation warnings when __new__ is stubbed using python 2.6

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by agora...@gmail.com on 26 May 2009 at 6:18

Attachments:

• stubout.py.diff
• test.py

[GoogleCodeExporter]

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)

Original comment by smidd...@gmail.com on 27 May 2009 at 11:14

[GoogleCodeExporter]

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!

Original comment by agora...@gmail.com on 28 May 2009 at 11:43

[GoogleCodeExporter]

Sounds good. :)

Original comment by smidd...@gmail.com on 28 May 2009 at 3:00

• Changed state: WontFix