Having __str__ not __repr__ as part of the matcher protocol is awkward

[Michael Hudson-Doyle]

For example, this is from MismatchesAll:

    def __str__(self):
        return 'MatchesAll(%s)' % ', '.join(map(str, self.matchers))

Wouldn't this:

    def __repr__(self):
        return 'MatchesAll(%r)' % (self.matchers, )

be much easier? This even seems more in the spirit of what __repr__ is usually used for than what testtools does now.

[Robert Collins (lifeless)]

repr often/always shows object ids and so forther, that aren't interesting or even desirable for the string representation of a matcher.

[Robert Collins (lifeless)]

I'm tempted to close this, but the question raised probably needs answering/further analysis. I'm not sure what or where though.

[Jonathan Lange (jml)]

The Python docs say that both provide a printable representation of an object. The differences are that str is supposed to be "nicely" printable, and that repr should try to return a string that could be evalled to create an equivalent object.

In practice, I find that a good repr is one that helps with debugging, which sometimes involves including the object id.

Having either of them as part of a public API feels wrong to me, since there's so much ambiguity of what they mean.

At an implementation level, it's a bug if a repr() could be improved to make debugging easier.

[Jonathan Lange (jml)]

I would now contend that, strictly speaking, __str__ is not part of the matchers protocol. It's just something a lot of higher-order matchers tend to use to print other matchers.

I would support a change that updated these matchers to use __repr__, and updated our built-in matchers to have high-quality repr implementations. I'd do it now, but I've got too many open PRs against testtools.

[Jonathan Lange (jml)]

https://github.com/testing-cabal/testtools/pull/181 in particular, which documents the matchers protocol.