← Back to team overview

testtools-dev team mailing list archive

[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