Not sure it's my place to comment here, but here are my 2 cents: I think Robert's proposal to have module functions is the only way to have a user-friendly and robust API, and it solves more than just the assert typo problem. (And yes, it would require moving the mock public API entirely to functions/classmethods).

To me, there's an underlying fragility in mock since the current API for `Mock` is not cleanly separated from the mocked API. This issue creates the problem of the  assert typos, and also creates problems with name conflicts (I've always thought the `.call_count` attribute was particularly likely to be clobbered).

The only bullet-proof way I can think of to ensure such a conflict does not take place is to separate the namespaces altogether, by moving the data out of the Mock object and into a global structure. E.g., `mock.Mock` could have a class attribute (say `mock.Mock.call_log`) tracking all of the calls to all mocks, and there could be a series of classmethods to query this store. Unfortunately, this design goes seriously against the grain of OOP, but we're essentially back to Robert's proposal.

A more OOP-friendly approach sacrifices the '100% clash-proof guarantee' and only provides a 'highly unlikely to clash' guarantee instead: Mangle the mock API namespace. Mock currently does this for its internal attributes (e.g., `._mock_parent`) but not for its public API (e.g., `.assert_called_once_with`). To remain user-friendly, of course we wouldn't require users to mangle names by hand, but would provide convenience functions to access these mangled attributes/methods, which puts us right back at Robert's proposal.