Using __repr__ or __str__ for own printable class?

[Steven Taschuk]

Quoth Donn Cave:
  [...]
> It's clear that the docs promote this idea, but they also hint at
> its half-baked quality - repr() evals to the original value, unless
> it doesn't.  I don't think the idea is clear at all.
> [...] The only kind of clarity this documentation possesses is
> when it lets you read into it what you already thought.  Not the fault
> of the documentation, though, but of the unsound ideas behind it.

I'm of the opinion that the ideas are sound; if there is a
problem, I think it must lie in the documentation.

The docs use the nice phrase "information-rich and unambiguous"
for the output of __repr__.  The notion that ideally we'd have
eval(repr(x)) == x follows from this; there can be no more
information-rich and unambiguous representation than one which
would cause the runtime to reconstruct the object.

But information-rich and unambiguous representations, however
useful for (e.g.) debugging, are not always easy to read or
understand; for the humans then, we'd like an "informal",
easier-to-read representation, whence __str__.

What's unsound here?

-- 
Steven Taschuk                           staschuk at telusplanet.net
"I'm always serious, never more so than when I'm being flippant."
                            -- _Look to Windward_, Iain M. Banks