Beyond __str__ and __repr__? (Was Re: Python doesn't know how to do math?)

[Donn Cave]

Quoth huaiyu at gauss.almadan.ibm.com (Huaiyu Zhu):
| David Bolen <db3l at fitlinxx.com> wrote:
|> instead.  The default output at the interpreter is to use repr() to
|> print an object, which shows the highest precision possible to best
|> assure that its output could be used to re-create the object.  The
|> print statement will use str() which is designed for "prettier" output
|> and will do some rounding.
|
| The current arrangement between repr and str has some shortcomings:
|
| - nested structures use repr for elements
| - repr is constrained by the desire to be inverse of eval for simple types
| - default repr for instances are optimized for object id, not content
| - str cannot differentiate between 2 and "2"
|
| It appears that another display level is needed, somewhat between repr and
| str.  Let's call it 'disp' here.  It is intended to be used for display in a
| controlled way, esp for nested structures.

Minus the floating point problem, is this function not identical to repr()?

It seems to me the crux of the problem is the notion that
repr is the inverse of eval.  It's fine with me if people
want to use this feature, but it is not by any stretch of
the imagination a reliable characteristic of Python objects.
I mean, eval(repr(sys.stdin))?  Class instances? etc.  We're
not looking at just an occasional exception, they're all over.
Again, if it works for someone, then that's great, but it's
a lost cause as a reliable feature.

Meanwhile, I really think str is poorly served by the common
notion that it's just prettier.  In my opinion, str is most
precisely suited to string conversion:  example that comes
to mind is Message.__str__ in rfc822.py, which returns its
header data.  repr() returns the usual information that it's
a Message instance.  Which is "prettier"?  The one that gives
you the kind of information you wanted!

In a context where I expect strings, I will use str(), in case
a data type conversion is necessary.  I use repr() when I want
a string that represents the object as such.  Now I'm not _using_
the object as data that must be a string, I'm generating a
description of it as an object.

So what about those damned floats?  Well, apparently we're generating
a more detailed description than we used to, and obviously that's
good for the people who want to marshal that way, but it's bad for
everyone.  I don't think this marshalling feature is worth it.

	Donn Cave, donn at u.washington.edu

| Here's what I think it should do:
|
| - disp(0.05)    -> "0.05", just like str(0.05).
| - disp("abc")   -> "'abc'", just like repr('abc').
| - disp([a,b,c]) -> '['+', '.join(map(disp, [a,b,c]))+']'.
| - disp(obj)     ->  obj.__disp__().
|
| Having and additional display method also reduces the need to override
| __repr__, which is the source of very confusing diagnostics when not done
| right (ie, when diagnostics are needed).
|
| Huaiyu