Proposal for improved safety of assert_that

[swails]

Alternative for #148 and #147 that more specifically targets usage patterns that are highly likely to be mistakes.

[offbyone]

The CI setup has been significantly revamped since this was created (and I have not had time to think through it in the interim). Please rebase this PR and let's see where it shakes out.

I'm cautiously okay with the basic idea of warning in the limited case where there is a single-arg call to assert_that that tests truth against a matcher. Anything stricter is not something I want to entertain at this time. That warning should also be trivially suppressable using standard warning suppression tools.

[rittneje]

I'm cautiously okay with the basic idea of warning in the limited case where there is a single-arg call to assert_that that tests truth against a matcher.

@offbyone I don't understand what you mean by this. Single arg calls are rare (in my experience) and aren't the problem. The root problem is that our developers (and reviewers) continue to erroneously expect assert_that(a, b) to do an equality check, whereas in reality it has the unintended behavior of merely asserting the truthiness of a, and thereby causes a faulty test to pass. I still contend that the simplest and best way of resolving this issue is to unconditionally emit a warning when the second parameter (i.e., matcher) is not a Matcher. Anyone who truly just wants a truthiness check should use a named parameter to make it unambiguous - assert_that(a, reason="..."). I don't believe that any other solution (including more clever or "Pythonic" warning conditions) can truly make this library safe for use, without introducing a breaking change.