Using __repr__ or __str__ for own printable class?

[Donn Cave]

Quoth Tim Peters <tim.one at comcast.net>:
| [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>.

I did concede that the documentation allows you to read into it what
you already understand to be true.  I find that these implementations
satisfy my own preconception of how repr and str should work.  That
happens not to conflict with the __str__ documentation, but it's so
vague that it's hard to imagine a real solid conflict (convenient to
whom, or what?  Just convenient in some way, your choice?)


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

Not at all.  There's no harm in mentioning that repr could work that
way and sometimes does.  It just should not be stated as a requirement,
it's silly and confusing to say you must but only if you can.


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

I think the original poster was really quite sensibly wondering under
what circumstances str() might be invoked on his object.  I won't pretend
that there's a great deal that can be said about that on any specific
level, but words like ``informal'' and ``convenient'' are worse than
nothing when not attached to some context.

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

Well, we've been over this, but I would be delighted.  I think it's
going to help to acknowledge that all Python features are exclusively
useful to developers, who are actually the end users of Python.

The fact that end users of a Python application are exposed more
commonly to the output of str(), says something about str's application
in a general sense - it's about transforming data, and that's what
users experience, data.

repr is about objects, which users do not experience.  I could go
on, but I think that's really enough.  It's a string representation
that is about the object qua object, and from this you can infer its
applications.  Objects implement data, and where you just want that
data, you use str.

Am I creating a new language here?  Obviously I am not, this is not
how Python ought to have worked, it's how it does work.  It's how
it ought to be documented.

	Donn Cave, donn at drizzle.com