[TIP] Is this a bug in unittest.mock, or am I missing something?

[John W]

I encountered my problem in Python3.4's unittest.mock, but I imagine
people on this list might be able to help (is there a better place?).

I made a SO post about this, too, but haven't seen much movement
there: http://stackoverflow.com/questions/42212433/what-is-wrong-with-this-simple-unittest-mock-use-case

Basically, `assert_has_calls` seems to be behaving in a strange way,
or else I am misunderstanding something - which is entirely possible,
as I'm new to unittest.mock.

I have some fairly small code that repro's the issue:

    $ cat test.py
    from unittest.mock import patch, call

    class Foo:
        def __init__(self):
            pass
        def my_method(self, value):
            pass

    def test_foo():
        with patch('test.Foo', autospec=True) as MockFoo:
            # Note: in the real code, this usage of Foo is off in some
other module.
            # Just putting it here for compactness.
            m = Foo()
            m.my_method(123)
            MockFoo.assert_has_calls([call(), call().my_method(123)])

    $ py.test test.py
    ... <snip long output> ...
    E               AssertionError: Calls not found.
    E               Expected: [call(), call().my_method(123)]
    E               Actual:   [call(), call().my_method(123)]


The list of calls seems to match exactly, yet the assert fails.
What's going on, here?

Oddly, if I remove the 'value' parameter of my_method (and the
corresponding 123 inputs), it works fine.

Also, if I do it this way instead, everything works:

    MockFoo.assert_has_calls([call()])
    r = MockFoo.return_value
    r.assert_has_calls([call.my_method(123)])

That makes sense to me, but I don't understand why it would be
different from the original case.

... Help?

Thanks
-John