Using __repr__ or __str__ for own printable class?

[Steven Taschuk]

Quoth Donn Cave:
> Quoth Steven Taschuk <staschuk at telusplanet.net>:
  [str : repr :: data : object ?]
> [...] But we're definitely on the
> same page here.  Your objection is probably reasonable, though
> arguable, but the thing is, we're on ground here that we can
> reason about.  It may be underspecified, but it isn't the kind
> of thing I call fuzzy.  I agree that it's worth a brief sentence
> or two, but at some point one has to leave it to the programmer's
> judgement what's actually going to be desirable.

Fair enough.  (I won't insist on "fuzzy"'s applicability in this
case.  Whether we call it fuzzy or not is, in the end, of merely
ritual significance.)

I certainly agree that it is highly desirable to have grounds on
which to reason about the quality of a given implementation of
__str__ or __repr__.  I will stipulate that the documentation as
it stands doesn't provide such grounds.

I also agree (as does the timbot, to judge by his posts in this
thread) that the matter must largely be left to the judgement of
the programmer; the best the documentation can do is state the
general principles and give examples of them at work.

  [draft revision of __str__ docs]
> |     This differs from __repr__() in that its primary audience is not a
> |     programmer inspecting the object during debugging.  What the
> |     primary audience is depends on the object: the __str__
> |     representation might, for example, be designed for display to a
> |     user of the application, or for processing by other code which
> |     requires a string.  Thus this representation might be less
> |     detailed, less precise, or in some way more convenient than that
> |     computed by __repr__.
  [...]
> The __str__ section could use more work.  [...]

I agree.  I've tried to describe it in terms of intended audience,
but am coming to doubt that that's a good way of describing
__str__.  (Though it works quite nicely for __repr__, imho.)

I wonder whether __str__ allows any description less vague than
"stringification as appropriate to the object".  The appropriate
stringification varies a great deal from object to object: numbers
and datetimes call for end-user-friendly representations;
rfc822.Message calls for the textual representation as per the
RFC; a class representing a blurb of bytecode might str simply
into the string of bytes.  And so forth.  They're all more
convenient than the corresponding reprs, but more convenient for
very different purposes.

> [...] I really think the last sentence is as
> wrong as it is right - sure it might be, or it might be more detailed
> etc.  Cf. rfc822.Message.__str__ - complete contents of the header.
> In what way is that less detailed or precise, or more convenient?
> It is however exactly the ``data''.

Yes, I suppose I have to agree that __str__ is sometimes more
detailed than __repr__.  (There's another nice example in
compiler.pyassem.Block, incidentally.)  I'll go along with
dropping that last sentence.

-- 
Steven Taschuk                                                   w_w
staschuk at telusplanet.net                                      ,-= U
                                                               1 1