Using __repr__ or __str__ for own printable class?

[Tim Peters]

[Tim, quotes the __repr__ docs
 http://www.python.org/doc/current/ref/customization.html
]

[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.

I do, but the variety of objects is messy.  The spirit of __repr__ is "do
the most faithful job you can, within reason".  Some objects simply can't be
reproduced faithfully with a comprehensible Python expression, and the docs
admit to that reality up front.

> Taken together with the __str__ documentation, the original poster saw
> this stuff and did not find it clear.

I believe that, but am not concerned by it.  There's usually more than one
way to convert an object to string that may be useful, and for some objects
there may be many distinct ways, and Python has two convert-to-string
special methods to cover two frequent uses:  friendly (str) and anal (repr).
I think these work very well for the builtin scalar types, but not so well
for the builtin container types (because str(container) applies repr() to
the containees).  It's also sometimes unfortunate that the interactive
prompt is wedded to __repr__ by default.  So it goes.  What to do with each
method is in large part art, and the teachable seem to do OK learning by
example.  Here's an example new in 2.3:

>>> import datetime
>>> t = datetime.date.today()
>>> print repr(t)
datetime.date(2003, 4, 16)
>>> print str(t)
2003-04-16
>>>

Fred Drake decided to make repr() and str() do those specific things for
dates, and it was instantly obvious to me, and to Guido, that those are
appropriate things for each to do.  Is it actually hard for you to see that
both match the doc's intents?  It can't be hard to see that the repr() does,
so maybe you can't see that the str() result is "more convenient or
concise"?  Hard to believe <wink>.

>>> print eval(repr(t))
2003-04-16
>>> eval(repr(t)) == t
True
>>>

> He learned that repr is ``official'', vs. the ``informal'' str.  This is
not
> explained.

Not to the point of an algorithm everyone can apply to a class and come up
with identical results, no.  That's why I call it art.  Going back to the
date example, if str(t) produced '04-16-2003', that would have been a poor
str() result, but "explaining why" requires dragging in arguments from human
interface design.  You can't expect the __str__ docs to cover that:  the
goals are explained briefly, and the rest is up to the programmer.

> The requirements for repr conflict, and the primary one is conceded to
perhaps
> not be practicable.

That's because sometimes it's not.  So what?  Because it may not always be
possible, you want the language to cut off the possibility of trying?

> The requirements for str are on the other hand silent on its intended
> application.

Applications are the user's business, not the language spec's.  If you can't
think of an application for "more convenient or concise; doesn't need to try
to be a Python expression", stay away implementing __str__.

> 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.

It's evident that more than one way of converting to string may be useful,
and that some ways are more useful for developers and others for end users.
Those are "the unsound ideas behind it".  They're not precise ideas, nor do
I believe they can be made precise.  Please tell us how *you* would design
the to-string facilities in a language -- sticking strictly to "sound"
ideas, of course.