[issue24653] Mock.assert_has_calls([]) is surprising for users

Irit Katriel added the comment: I agree that the confusion was probably due to assumptions rather than a misreading of the doc, and I would not object to closing this issue. However, Robert did object so I would like to suggest an adjustment that may help: Currently the documentation of

[issue24653] Mock.assert_has_calls([]) is surprising for users

Serhiy Storchaka added the comment: alist.extend([]) is also a special case, but it is not explicitly documented, because it is not exceptional. -- ___ Python tracker ___

[issue24653] Mock.assert_has_calls([]) is surprising for users

Inada Naoki added the comment: > I opened the bug because we have evidence that users find the current > documentation confusing. Saying that its not confusing to us doesn't fix the > confusion. Is there evidence people get confused by the document? I suppose people get confused because

[issue24653] Mock.assert_has_calls([]) is surprising for users

Robert Collins added the comment: I'm reopening this because I don't agree. I opened the bug because we have evidence that users find the current documentation confusing. Saying that its not confusing to us doesn't fix the confusion. Why should we mention the special case of an empty set?

[issue24653] Mock.assert_has_calls([]) is surprising for users

Karthikeyan Singaravelan added the comment: > Are the correct methods advertised in the right place? (I don’t use mock so > I forgot if there is a method to assert not called or if it’s > assertEqual(mock calls count, 0) or some False property) There is assert_not_called

[issue24653] Mock.assert_has_calls([]) is surprising for users

Éric Araujo added the comment: > And when people understand this API checks inclusion, calling with empty list doesn't make sense at all. I can see a thought process being «all my other tests use thing.assert_has_calls([call0, call1]), here let’s check there are no calls with

[issue24653] Mock.assert_has_calls([]) is surprising for users

Inada Naoki added the comment: I concur with Serhiy. Current document and example describe clearly that this API is for checking inclusion, not equality. Current example: """ >>> mock = Mock(return_value=None) >>> mock(1) >>> mock(2) >>> mock(3) >>> mock(4) >>> calls = [call(2), call(3)]

[issue24653] Mock.assert_has_calls([]) is surprising for users

Serhiy Storchaka added the comment: Why this case should be explicitly mentioned? Is it an exception from some rules? Is the empty list special? Does existing documentation say that assert_has_calls([]) should raise an exception? -- nosy: +serhiy.storchaka

[issue24653] Mock.assert_has_calls([]) is surprising for users

Change by Srinivas Reddy T : -- keywords: +patch pull_requests: +9245 stage: -> patch review ___ Python tracker ___ ___

[issue24653] Mock.assert_has_calls([]) is surprising for users

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24653] Mock.assert_has_calls([]) is surprising for users

Robert Collins added the comment: Ok, so as a doc bug this should still be tracked here - I'm going to reopen it to reflect that, hope thats ok. -- assignee: - docs@python components: +Documentation nosy: +docs@python resolution: not a bug - status: closed - open title:

[issue24653] Mock.assert_has_calls([]) is surprising for users

Changes by Antti Haapala an...@haapala.name: -- nosy: +ztane ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24653 ___ ___ Python-bugs-list mailing