-
Notifications
You must be signed in to change notification settings - Fork 11
Description
mock_foo.assert_called_with(ARG % 2 == 0)
mock_foo.assert_called_with(ARG.id == 42)
mock_foo.assert_called_with(ARG('foo') == 'FOO')
# etc.as an equivalent of:
mock_foo.assert_called_with(ArgThat(lambda x: x % 2 == 0))
mock_foo.assert_called_with(ArgThat(lambda x: x.id == 42))
mock_foo.assert_called_with(ArgThat(lambda x: x('foo') == 'FOO'))
# etc.In other words, an instance of a magic class with all feasible operators overloaded to produce lazy callables. ARG itself would be just such lazy callable corresponding to an identity function.
Caveats
Not every Python operator is overloadable, and/or are notable exceptions.
Of those that are, some have limitations (e.g. in can only return boolean).
Pitfalls with function calls: foo(ARG) doesn't work like the user may have expected.
How to distinguish == used in a predicate itself rather than for final matching? It would probably require a wrapper (i.e. M(ARG.id == 42) vs. just ARG.id == 42).
Alternatively, relational operator would produce a final matcher while __getattr__ or __getitem__ or other operators would result in an "unfinished" matcher. (This would work better if we could signal when a matcher has been created but not used).