testtools-dev team mailing list archive
-
testtools-dev team
-
Mailing list archive
-
Message #00540
[Bug 686807] Re: Having __str__ not __repr__ as part of the matcher protocol is awkward
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.
** Changed in: testtools
Status: Incomplete => Triaged
** Changed in: testtools
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of testtools
developers, which is subscribed to testtools.
https://bugs.launchpad.net/bugs/686807
Title:
Having __str__ not __repr__ as part of the matcher protocol is awkward
Status in testtools:
Triaged
Bug description:
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.
References