__str__ vs. __repr__

[Tim Peters]

>> repr(obj) should return a string such that
>>    eval(repr(obj)) == obj

[Toby Dickenson]
> I don't understand the motivation for this requirement. Why would
> anyone want to pass such a string to eval? If you anticipate the need
> for reconstructing the object from a textual representation, then
> surely pickle is a better option?

This was well covered by others (not everything of common interest can be
pickled; and pickle strings, while portable, are wholly unreadable by
people).

> ...
> OK, so repr as it stands today is clearly not suitable for formatting
> for people,

It's much better suited for that than is pickle.  That is, people can and do
cut & paste reprs with confidence, and even edit them by hand.  So, indeed,
the requirement at the top of the msg doesn't capture *everything* a good
repr should do.

> and is less than ideal for formatting for the machine.

Based on the repr(float) example?  That one is easy to repair.  So long as
interactive mode uses repr() for raw expressions, though, and containers
don't "pass str() down", most people won't want to see the "extra" digits
most of the time.

> However there is a third audience for who it is ideal, the programmer,
> who need a representation for use in development tools such as
> debuggers, or the interactive mode.

People (no, not even programmers <wink>) aren't that monolithic; e.g., in
development tools it's likely you're going to want to see the repr() of your
own objects and the str() of mine.  I'm not trying to address that --
there's only so much we can squeeze out of two functions.  It would be a
real help if those two (repr & str) had clearly understood purposes,
though -- they would cover more of the space if they weren't treated like
fuzzy synonyms in practice.

> Tim's Rat class is a good example of how __repr__ should not be
> implemented, because it exposes the internal representation of the
> object, not the external value.

Beg to differ:  it's an excellent example of how __repr__ should be
implemented.  The information in a *typical* Rat can require terabytes of
string space to represent if expressed as, e.g., a decimal expansion.  It's
a case where "the internal representation" is no accident:  a pair of longs
is one of a very few tractable ways to capture the object's true value.
Approximations are fine for __str__, though (and, although I didn't show it,
Rat.__str__ supports a dozen options for making nice-looking and compact
approximation strings -- alas, it's hard to talk Python into *invoking*
Rat.__str__!).

> However, using a small number of digits for repr(float) does make
> sense because it still provides sufficient precision for most
> programmers.

See above:  I told you you'd want to see the str() of everyone's objects
except your own <0.5 wink>.  This isn't a joke to people who use floats
seriously -- just as you take your objects seriously.

most-americans-don't-give-a-rip-about-o-umlaut-either-ly y'rs  - tim