Using __repr__ or __str__ for own printable class?

[Steve Holden]

"Steven Taschuk" <staschuk at telusplanet.net> wrote in message
news:mailman.1051490038.11587.python-list at python.org...
> Quoth Donn Cave:
> > Quoth Steven Taschuk <staschuk at telusplanet.net>:
> > ...
> > | I've submitted a documentation patch for the __str__ and __repr__
> > | docs, following ideas discussed in this thread:
> > |     <http://www.python.org/sf/727789>
>   [...]
> > I still think that the normal usage of __str__ can be directly
> > described as a data conversion to type string.  I know you don't
> > find that completely illuminating on its own, but I think it does
> > convey an essential idea that is otherwise likely to be missed.
> > See for example the __str__ and __repr__ definitions in Cookie.py.
>
> Hm... "conversion to type string".  So under this concept str()
> converts an object to a string, while repr() represents the object
> in a string, right?  Is this what you're saying when you
> distinguish "the data as a string" from "the object as a string"?
> If so, I quite like it.
>
</lurk>
Finally, the murk lifts and a dim light becomes perceptible. "str() is what
the users will recognize. repr() is what the programmers will thank you
for."

The print __str__()/__repr__() dichotomy is probably the best compromise for
the average Python user.

> (For some reason convert/represent sits better in my brain than
> data/object.  Don't ask me; I just think here.)
>
How about "use/program". It isn't valid to complain that programming an
object is using it, since that objection qualifies you as a programmer.

> > Since this apparently isn't as obvious to you as it is to me, you
> > may be in a better position to explain it if I can convince you
> > that there's something to it.  [...]
>
> *chuckle*  True.  (Not that I'm in any special position vis a vis
> changing the documentation.  Quite the contrary.)
>
Everybody is in the *same* position where changing the documentation is
concerned: if you can think of a change that retains existing clarity to
existing audiences and makes things plainer to others, go ahead and propose
the change. I think it's fabulous that I have been able to lurk this long as
this. Now the horrible truth can be exposed: you are *just as responsible as
I am* for maintaining the documentation *and no more*.

SourceForge is open source. Find out about bug reports: the developers
aren't [all] nazis ;-)

> > [...] If we can decide on some central
> > notion behind normal __str__ usage, the examples will make more
> > sense and it won't be necessary to describe __str__ as "not __repr__".
>
> I entirely agree.  I'll have to think about the notion of
> conversion to type string and see if I can devise a more
> satisfactory explanation of __str__ in those terms. (Further
> bulletins as events warrant.)
>
you guys-are-doing-pretty-well-by-youselves-ly y'rs  - steve
--
Steve Holden                                  http://www.holdenweb.com/
Python Web Programming                 http://pydish.holdenweb.com/pwp/