Using __repr__ or __str__ for own printable class?

Donn Cave donn at
Tue Apr 29 08:15:46 CEST 2003

Quoth "Steve Holden" <sholden at>:
| "Steven Taschuk" <staschuk at> wrote in message
| news:mailman.1051490038.11587.python-list at
|> 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."

Ouch, next someone will observe that str() should be friendly.  For me,
the murk starts rolling in at this point.  I'm sure _when_ str() output
is intended to be presented to someone, its success can be expressed in
terms of how friendly or recognizable it is, but that seems rather
generally true of anything and hard way to get specific about str().
Taken on its own, it has the potential to drag in an infinite number
of considerations (what education does this user have, etc.), or be
sort of irrelevant (where it isn't clear when or how the data will be
presented to anyone.)

One interesting thing about this discussion is that I suspect we all
would implement essentially similar __str__ and __repr__ functions,
even if we can't understand the concept in similar terms.

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

I didn't understand this sentence.  How does "print" figure in there?
Is the average Python user actually a computer programmer, or are you
talking about a user of software that happens to be written in Python?
The former, I guess?  What is the best compromise - the various ways
repr() and str() have actually been used lo these many years, or their
currently documented normative use?  Is this a lot of questions to ask
about such a short sentence?

	Donn Cave, donn at

More information about the Python-list mailing list