__str__ vs. __repr__

[Donn Cave]

Quoth "Tim Peters" <tim_one at email.msn.com>:

| Let me back off to what repr and str "should do":
|
| repr(obj) should return a string such that
|     eval(repr(obj)) == obj
| I'd go further and formalize a property that's currently honored but
| implicitly:  the string returned by repr should contain only characters c
| such that
|     c in "\t\n" or 32 <= ord(c) < 127
| i.e. it should be restricted to the set of 7-bit ASCII characters that the C
| std guarantees can be read back in faithfully in text mode.  Together, those
| properties spell out what repr() is "good for":  a highly portable and
| eval'able text representation that captures *everything* important about an
| object's value.

For real?  I'm very used to seeing repr's that don't eval at all -

'<socket object, fd=3, family=2, type=1, protocol=0>'
"<open file '<stdout>', mode 'w' at 80005660>"
'<exceptions.NameError instance at 80048ae0>'

Now it's fine with me if the author does choose to implement repr that
way, it's just hard to imagine it could be meaningfully implemented by
all objects, or that there's any purpose in trying.

Well, really I guess I would prefer that authors _not_ try to capture
*everything* important, if that means a large data dump.  repr is used
in lots of places, like the interactive interpreter, where the output
only has to be roughly indicative, and I have never seen and can't find
any example of its use with eval or in any context where it has to be
definitive.

If there are folks who want to provide this functionality at the expense
of making a string that's unusable for repr's normal applications, 
they should put it in a different function.  

| In contrast, str() should return a string that's pleasant for people to
| read.  This may involve suppressing obscure or minor details, displaying it
| in a form that's inefficient-- or impossible --to process, or even plain
| lying.  Examples include the Rat class I used before (the ratio of two huge
| integers is exact but unhelpful), a DateTime class that stores times as
| seconds from the epoch (ditto), or a Matrix class whose instances may
| contain megabytes of information (and so a faithful repr() string may be
| intolerable almost all the time).

Bah.  If we get str() because it's pleasant to read, aren't we worried
that repr() will be harsh and stressful?  Will one repr() too many send
one of us into a homicidal rage one of these days?

Let us think about taming the cruel repr()!  If I may speculate on what
you're trying to say, str() is pleasant because it shows the data in
form that has been digested for human consumption.  In contrast to
repr(), which is intended for the machine.

But as I don't agree with with the latter, I don't have to agree with
the former either.  On the contrary, it's str() that's intended for the
machine, and repr() for the human.  Consider rfc822, one of the three
Python modules in the standard distribution that actually implements
__str__:

>>> fp = open('mimetools', 'r')
>>> m = rfc822.Message(fp)
>>> str(m)
'Path: news.u.washington.edu!logbridge.uoregon.edu!news.mind.net!not-for
-mail\012From: dragondm at integral.org (The Dragon De Monsyne)\012Newsgrou
ps: comp.lang.python\012Subject: RFC complient mimetools...\012Date: 29 
Sep 1999 13:27:03 GMT\012Organization: InfoStructure - Ashland, OR\012Li
nes: 443\012Sender: dragondm at polar.integral.org\012Message-ID: <7st437$r
9s$2 at utah.laird.net>\012NNTP-Posting-Host: ip202.mind.net\012Mime-Versio
n: 1.0\012Content-Type: text/plain; charset=us-ascii\012X-Newsreader: kn
ews 1.0b.0\012Xref: news.u.washington.edu comp.lang.python:68258\012'

Pleasant, eh? [wink, wink, nudge, nudge]  I wrapped the lines, in case
the original line length of 529 might hurt someone's software.

So look at the way it's really used.  repr is for us, str is for the
machine.  Now for sure, there are quite a number of objects out there
out there that don't repr as readable as they could, but I think very
few of them are that way because they didn't get a chance to use their
str instead.

	Donn Cave, University Computing Services, University of Washington
	donn at u.washington.edu