Why isn't this a bug?

[Donn Cave]

Quoth "Russell Blau" <russblau at hotmail.com>:
| "Jonathan Hogg" <jonathan at onegoodidea.com> wrote in message
| news:B94F68F5.D936%jonathan at onegoodidea.com...
|> On 7/7/2002 21:12, in article aga7af$jsvv9$1 at ID-76829.news.dfncis.de,
|> "Russell Blau" <russblau at hotmail.com> wrote:
|> [...]
|> > Of course, if someone would like to explain why something so simple and
|> > intuitive is a "bad idea," please enlighten me.  ;-)
|>
|> I think the problem is that you're considering an implicit behaviour to be a
|> feature. The rough meaning of 'str' and 'repr' is:
|>
|>     repr - return a string representation of an object (ideally such that
|>            the string can be 'eval'ed to re-produce the object)
|>
|>     str  - convert an object into a string
|>
|> For numbers, these two behaviours are easily defined. But for tuples and
|> lists there is no obvious behaviour for 'str'. What does it mean to turn a
|> tuple or a list into a string? In the absence of a defined behaviour, the
|> interpreter falls back on just returning 'repr' of the object.
|
| Well, technically you're right.  The documentation just says that
| "str(object)" will return a printable string representing "object".  It
| does that, so it's not a bug.  However, the language does define two
| different functions (str and repr) for representing objects as strings.
| There presumably is a reason for having two different functions and two
| potentially different representations of the same object.  Given that,
| why shouldn't the representations of lists, tuples, and dicts recognize
| this distinction?  It would seem more logical, and more understandable
| to newbies, if "repr(sequence)" recursively called "repr()" on its
| elements [which it does], and "str(sequence)" recursively called "str()"
| on its elements [which it doesn't].  However, I'll agree that this is
| more a matter of "taste" than of right vs. wrong.

I think that might be more symmetrical, but I disagree that it would
be more logical - as perhaps you do too, if you think it's a matter
of taste.

I don't seem to be able to explain it more clearly than Jonathan Hogg
does above, because he hit the nail right on the head.  Lists don't
have any rationale for a distinct str function, you're really seeing
a repr.

The kind of object that will have a distinct str function is usually
one that contains some significant string data.  Obviously, a string
itself contains string data.  rfc822.Message, various classes in the
Cookie module.  The resulting string data is not a representation of
the object, for you to look at, it's what you would send to a mailer
or a browser.

The problem with floating point is that its repr/str split was done
with a completely different perspective, one that makes little sense
to me but is enshrined in documentation - repr is reversible, kind
of a lightweight (and not at all reliable) marshalling function,
and str is a "nice" representation (whatever that means.)

But then when 2.0 introduced the full precision repr(float), people
very much did not like it.  They should have been delighted, because
it's now more precisely reversible, but we all want a "nice" repr,
not a reversible one.  A third function would sure help resolve the
problem, but it would be a lot easier to just go back to the 1.5
repr(float).

	Donn Cave, donn at drizzle.com