Using __repr__ or __str__ for own printable class?

[Donn Cave]

Quoth Steven Taschuk <staschuk at telusplanet.net>:
...
| Looking back over your posts in this thread, I see a few kinds of
| objection to the current documentation.
|
| First, there's the description of __repr__ and __str__ in terms of
| fuzzy properties their output should have -- "informal" vs
| "official", "convenient" vs "complete", and the like; you feel
| that these descriptions are unclear.  For this problem, a few
| examples would certainly help to clarify the intended meanings of
| these terms.  It might also help to give examples of where these
| representations would normally be used -- for debugging output,
| for normal logging, for display to the user of the application.

I think the terminology is worse than unclear.  The lessons drawn
from examples that appear along with this text are going to be
a function of the text, and hence also misguided.

| Second, I have some sense that you feel these terms are not merely
| unclear but misleading or wrong.  Is this true?  If so, do you
| have alternative fuzzy terms in mind (the "data" vs the "object"),
| or would you prefer that the documentation avoid fuzzy terms
| entirely, and only give examples?

The data vs. object distinction is the best I can do so far.  It
isn't all that fuzzy, either.  It's vague, in that it applies to
a very high level of generality, but it does not seem ambiguous
to me.

| Third, you (and others) specifically object to the notion that if
| possible one should have eval(repr(x)) == x.  Would you want this
| notion to be omitted entirely?  Mentioned as possible and
| sometimes good?  Described as highly desirable, though sometimes
| infeasible?  (Imho the docs currently do this last, though perhaps
| they could do so more clearly.)

It would be fine to document current practice.  __repr__ sometimes
supports that application, on purpose.  The problem is that the
current documentation tries to make it a requirement, as if there
might be some penalty for not supporting it.  On the contrary,
there is little reason to actually do this, and plenty of reasons
not to (can't, awkwardly large, requires introspection that breaks
abstractions, etc.)  I don't think the documentation needs to get
into that, just document current practice.

	Donn Cave, donn at u.washington.edu