Should-DSL doesn't work if the left-side (actual) object overrides __or__

[rodrigomanhaes]

If the actual object (the left-side one) overrides the or operator, Should-DSL breaks.

class Foo:
    def __or__(self, other):
        return True

foo = Foo()
foo |should| be(foo)

will have as result:

---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

/home/rodrigo/<ipython console> in <module>()

NameError: name 'be' is not defined

This happens because foo has an or method. When foo | should is evaluated, foo's or is called rather than should's ror. Since ror creates all matchers, if it isn't run, everything breaks.

[CharString]

I noticed this when I tried to stub things out using dingus; a Dingus overrides all magic operators and returns Dinguses, which is really handy for a property for a test double. It records calls for stubbing, and can return prepared values for mocking. I love it.

But given it implements all operators the alternate operator patch wouldn't solve anything here. The | hack is clever, but not very idiomatic.

Still I couldn't resist hacking up a matcher that checks the .calls of a Dingus in a readable way. The package is called should-dingus.

[kaukas]

A (somewhat hacky) fix for these cases could be

should(foo) | be(foo)

Less readable but no clashes guaranteed. Also very easy to implement:

Should.__call__ = Should.__ror__