Why isn't this a bug?

[Russell Blau]

"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.

> It's best not to rely on implicit conversions.

Point taken.

--
I don't actually have a hotmail account; but I do have one on excite.com
if you really want to get in touch with me.