__str__ vs. __repr__

[Donn Cave]

Quoth "Thomas A. Bryan" <tbryan at python.net>:
...
| The problem is that this thread is the first time many of us have 
| ever thought about the problem.  I've never noticed those two lines
| in the library reference, and I haven't seen the str/repr distinction 
| clearly made anywhere else.  Furthermore, since the interactive i
| nterpreter *does* use repr(), many of us make __repr__ return the 
| human readable form so that we can easily test our classes.
|
| So, what I'm hearing is:
| 1. __str__ *should* be a human readable string
| 2. __repr__ *should* be a representation that can be eval'd back to the 
|    original object
| 3. This convention is not widely known, but
| 3b. the interactive interpreter discourages the convention by using 
|    repr to show the result of an expression

One of the problems here is that there are not two types of string
representations, but at least three.

1. Human readable representation of object.  Interpreter should display
   this in interactive use, for example.
2. Machine readable representation of object, for eval.
3. Machine readable object qua string - intentionally, not the
   object's faithful representation, but what it would be if it
   had been a string.  What the author of rfc822.Message.__str__
   appears to have had in mind, for example.

I don't see how any two of these three can be made compatible enough
to comfortably use the same implementation.  When usage parted with
documented intentions, it probably wasn't just a lot of people failing
to read the documentation.  There's a fundamental need for a machine
__str__ that's different from a machine __repr__, and the machine
__str__ is worse for general display purpose if it's intentionally
inaccurate.

Now I'm arguing that one reason many of us have never considered
this issue is that the current implementation is the best resolution
of these conflicts.  It's not completely OK, there is dissatisfaction
because people wish for the eval-able repr, but if we change course
in favor of the documented behavior, it's going to pinch somewhere else.

We already have a glimpse of this in the special cases that would
apparently be necessary.  A string's str is of course itself - string
qua string - and its repr adds quotes, and that works out fine the way
we do things now.  Change the context in which these are used - like
make str(container) use str() for contents - and you realize that the
repr was really a lot more friendly for some objects, like strings.
I'm saying this is not just a quirk of strings, it's because a string
is computable data and that's what we do use str() for.

Wouldn't it be great if that eval-able string could be shifted to
another function?  Then if you exercised that function, you could
be more or less sure to really get something the author intended to
eval with a sensible result.  Or you get an AttributeError.  Not a
string that may or may not eval, when you get around to trying it.

	Donn Cave, donn at u.washington.edu