__str__ vs. __repr__

[Guido van Rossum]

[David Ascher]
> I certainly appreciate the justification for the current behavior, which I
> didn't really understand either.
> 
> I have two suggestions which would make the current read-eval-print
> behavior somewhat more palatable to me:
> 
>  -- container types (lists, dicts, tuples) should have both repr and str
>     methods, even if they differ only in the methods of the contents that
>     they call.  You can make the str methods use the repr-type display
>     (with brackets/parens/braces and commas), as that wouldn't break
>     anyone's expectations (since that's what is currently being used), and
>     would 'solve' the current inconsistency.
> 
>     I understand str output is meant to be human readable -- that
>     doesn't mean that []'s and ,'s can't be used.

I'm reluctant but Tim's dictionary-of-rationals example suggests
you're right.

>  -- make the str of a long integer not have the postfix L.  After all, if
>     the __str__ is supposed to be for human consumption, the L is no more
>     useful than the quotes around strings.  

Good one!

> The issue of determining the printability of characters is one *I*
> wouldn't touch with a 10-foot snake.

Unfortunately I will have to touch this...  I cannot think of
something better than isprint(), which is designed for this.  But the
weirdness is that if I write a tiny test program, the default (== C
locale) behavior is for isprint() to return false for anything over
\177; however in Python, it seems to always assume a Latin character
set.  To be precise, the following non-ASCII characters are considered
printable: 'ÔÕØÙÚßàçèéêìíîðñòôõöøùüýþ'.  Is there anything I may have
forgotten about isprint()?  Using the Python locale module's
setlocale() function doesn't seem to make a difference, which is also
weird (Python doesn't call setlocale(), so it *should* default to the
C locale.  (And yes, I'm including <ctype.h>.)

I have one more suggestion myself: add an "expert mode" where values
are displayed using str() instead of repr() by the read-eval-print
loop.  I call it expert mode because it's only useful when (a) you are
manipulating custom types like Tim's rational number class, and (b)
you are aware of the ambiguities and risks of using str() (garbage
characters and multiple interpretations).

By the way, there's another issue here that fortunately hasn't muddled
the discussion.  The C API allows an object to specify *three* ways of
formatting itself: str(), repr() and print-to-file.  The print-to-file
call should faithfully mimic either str() or repr() depending on a
'mode' argument flag; however some 3rd party extensions (none in the
core distribution as far as I know) have a str() or repr()
implementation that deviates from print-to-file.  These should be
fixed.  Forget I even mentioned this in this thread, though!

--Guido van Rossum (home page: http://www.python.org/~guido/)